Event Delivery for everyone ?

Maybe it’s time for your application to think event-driven instead of request-driven. Well Oracle has it all figured out.

The current release of Oracle Fusion Middleware contains an Event Delivery Network. This network, that has been part of the product for almost 3 years, allows composite to communicate on events instead of requests.

Basically another level of loose coupling can be attained. By using these events it is very easy to incorporate multiple listeners.

Often though developers see this is a handy feature to handle simple jobs like synchronous email communication or custom notifications etc.

One drawback is how the transaction (rollback) is handled between the publisher and subscriber but more importantly between the all the subscribers.

Let me show you what happens based on the documentation of Oracle Fusion Middleware concerning the consistency…

•   one and only one

Events are delivered to the subscriber in its own global (that is, JTA) transaction. Any changes made by the subscriber within that transaction are committed after the event processing is complete. If the subscriber fails, the transaction is rolled back. Failed events are retried a configured number of times.

•  Guaranteed

Events are delivered to the subscriber asynchronously without a global transaction. The subscriber can choose to create its own local transaction for processing, but it is committed independently of the rest of the event processing. The event is guaranteed to be handed to the subscriber, but because there is no global transaction, there is a possibility that a system failure can cause an event to be delivered more than once. If the subscriber throws an exception (or fails in any way), the exception is logged, but the event is not resent.

•  immediate

Events are delivered to the subscriber in the same global transaction and same thread as the publisher. The publish call does not return until all immediate subscribers have completed processing. If any subscribers throw an exception, no additional subscribers are invoked and an exception is thrown to the publisher. The transaction is rolled back in case of any error during immediate processing.

Clearly the choice of the developer can clearly impact the way the event is handled and treated by the different listeners.
As a result this very nice and functional feature needs to be used with causing for “regular” notifications.

After reading this post many might be wondering… … Why not just use JMS ?

Well I’ll leave that up for another post.