Reliability : MDB or @Asynchronous

[Dieter Quickfend]

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]

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]

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]

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]

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]

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]

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]

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]

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.