• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

Reliability : MDB or @Asynchronous

 
Bartender
Posts: 543
4
Netbeans IDE Redhat Java
  • 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?
 
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
 
Ranch Hand
Posts: 145
8
Mac MySQL Database Java 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
 
author & internet detective
Posts: 40198
816
Eclipse IDE VI Editor Java
  • 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
Netbeans IDE Redhat Java
  • 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...
 
Sheriff
Posts: 10445
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
Netbeans IDE Redhat Java
  • 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.
 
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
Netbeans IDE Redhat Java
  • 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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    Bookmark Topic Watch Topic
  • New Topic