Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Reliability : MDB or @Asynchronous

 
Dieter Quickfend
Bartender
Posts: 543
4
Java Netbeans IDE Redhat
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the title says it all. Which is more reliable? If you don't have the topic/queue in between, you are more reliable because it's one less possible point of failure. Then again, a queue can be persistent, storing its messages in case of failure. If failure occurs on the application server, the messages will be persisted and can be processed when the server is rebooted. When one uses @Asynchronous, failure will cause message loss. But when failure occurs, your entire application will be down.

Suppose I have messages to send which may take milliseconds to process, yet may also take minutes to process, depending on a message selector. Which would be the best choice, and why?
 
Andres Olarte
Ranch Hand
Posts: 46
2
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would say a MDB (with a persistent queue) is more reliable than @Asynchronous. I think you pointed out why on your own message. Having more points of failure doesn't make an architecture less reliable, if the architecture is designed to work around such failures. I think persistent queues do exactly that.

Andres
 
Mike Degteariov
Ranch Hand
Posts: 145
8
Java Mac MySQL Database Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey Dieter,

If you use EJB3.1 (Java EE 6), and you want your asynchronous call to be reliably executed, but do not want to mess with MDB for whatever reason, you could use single-action timer with persistence set to "true" and minimal (1 ms) delay.
When you register a persistent timer, the container sore the timer information in persistent storage, so it will service server crash or restart.

--
Cheers,

Mike
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 35279
384
Eclipse IDE Java VI Editor
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Andres Olarte wrote:I would say a MDB (with a persistent queue) is more reliable than @Asynchronous.

Agreed. If there is a problem in the middle of @Asynchrnous, you don't have the recovery of the queue from a MDB.
 
Dieter Quickfend
Bartender
Posts: 543
4
Java Netbeans IDE Redhat
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeanne Boyarsky wrote:
Andres Olarte wrote:I would say a MDB (with a persistent queue) is more reliable than @Asynchronous.

Agreed. If there is a problem in the middle of @Asynchrnous, you don't have the recovery of the queue from a MDB.

Do you mean that, on a rollback due to the circumstances in @Asynchronous, the persistent timer won't try again? The specs on persistent timers say they do...
 
Jaikiran Pai
Marshal
Pie
Posts: 10447
227
IntelliJ IDE Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dieter Quickfend wrote:
Jeanne Boyarsky wrote:
Andres Olarte wrote:I would say a MDB (with a persistent queue) is more reliable than @Asynchronous.

Agreed. If there is a problem in the middle of @Asynchrnous, you don't have the recovery of the queue from a MDB.

Do you mean that, on a rollback due to the circumstances in @Asynchronous, the persistent timer won't try again? The specs on persistent timers say they do...


@Asynchronous is independent of timers. EJBs can have @Asynchronous methods which aren't invoked through timeout methods. In such cases, no persistence of "events" is involved and there's no retry.
 
Dieter Quickfend
Bartender
Posts: 543
4
Java Netbeans IDE Redhat
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks. I guess that clears it up. I also found this snippet from EJB in Action:

Asynchronous session beans are intended to be lightweight. This means that they do not provide any reliability
guarantees. This means that, if a container crashes while an asynchronous method is getting executed, the method
will not recover. Asynchronous beans are also not loosely coupled, meaning that a client holds a direct reference to
the asynchronously invoked session bean. If you require reliability and loose coupling and not just asynchronous
processing, you should consider message-driven beans.


So I will have to use either an MDB or @Timeout adding my data as timer info.

A shame that. It would be sleeker if @Asynchronous had a "persistent" option for fire-and-forget strategies, perhaps using @Timeout under the hood. I would say if you're using EJB's on the project, reliability is a likely concern.
 
Katrin Perry
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Something else which wasn't mentioned above. Another reason why MDB is a much more reliable option is that it can be transaction aware:

"A message can be delivered to a message-driven bean within a transaction context, so all operations within the onMessage method are part of a single transaction. If message processing is rolled back, the message will be redelivered. " From Oracle Java EE 6 tutorial on MDB

Regards
 
Dieter Quickfend
Bartender
Posts: 543
4
Java Netbeans IDE Redhat
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Katrin Perry wrote:Hi,

Something else which wasn't mentioned above. Another reason why MDB is a much more reliable option is that it can be transaction aware:

"A message can be delivered to a message-driven bean within a transaction context, so all operations within the onMessage method are part of a single transaction. If message processing is rolled back, the message will be redelivered. " From Oracle Java EE 6 tutorial on MDB

Regards

They're all transaction aware... It's the redelivery that does it.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic