Looking for an architectural pattern to solve the following problem.
In my architecture, I have a Stateless EventDispatcher EJB that implements:
public void dispatchEvent(MyEvent ev)
This method is called by a variety of other EJBs in their business methods. The purpose of my EventDispatcher is to hide the complexity of how events are dispatched (be it JMS or other mechanism).
For now let's assume my bean is using JMS. So it simply looks at the event passed it, and builds JMS messages and dispatches them to the right topic. It can produce several JMS messages and they are only sent if the surrounding transaction ends up being committed successfully (XA transaction).
Problem: I may be looking at transactions where I send thousands of individual messages. Some messages might become invalid because of other things that happened in a transaction (object Updated and then later Deleted). So I need a good deal of logic to "scrub" messages based on a context, and make a final decision on if it is one big JMS batch message or multiple small ones.
Solutions: What I would like to is use some sort of "TransactionalContext" object and use it in my Stateless EJB to "Buffer" all the events. Then I need a callback of some sort to tell me the transaction is about to commit. This is something similar to how we use EntityManager, i can make changes to entities, and it holds onto changes and is shared between stateless EJBs. At "flush" time (transaction complete) it does its logic to figure out what SQL to execute. I need a TransactionContext available to my stateless bean that has a unique session per transaction, and, has a callback as the transaction is about to complete.
What would you do?
Note that I am NOT in a valid CDI context, some of these transactions are starting because of #Schedule timers. Other transactions begin because of JMS MDBs.
I believe the thing I am looking for is the TransactionSynchronizationRegistry.
http://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchronizationRegistry.html#putResource(java.lang.Object
Related
I want to use SAGA pattern in my Spring Boot Microservices. For example in order of customer, when the order created, an event like OrderCreatedEvent produced and then in customer microservice the listener on OrderCreatedEvent Update the customer credit and produce CreditUpdateEvent and ... .
I use session transacted JmsTemplate for event producing. In javadoc of JmsTemplate said that the JMS transaction commited after the main transaction:
This has the effect of a local JMS transaction being managed alongside the main transaction (which might be a native JDBC transaction), with the JMS transaction committing right after the main transaction.
Now My question is how can I handle below scenario:
The main transaction committed (for example order recored committed) and system was unable to commit the JMS transaction (for any reason).
I want to use SAGA instead of two phase commit but I think just SAGA move the problem from order and customer service to order service and JMS provider.
SAGA hints the issue:
There are also the following issues to address:
...
In order to be reliable, a service must atomically update its database and publish an event. It cannot use the traditional mechanism of a distributed transaction that spans the database and the message broker. Instead, it must use one of the patterns listed below.
...
The following patterns are ways to atomically update state and publish events:
Event sourcing
Application events
Database triggers
Transaction log tailing
Event Sourcing is special in this list as it brings radical change on how your system stores and processes data. Usually, systems store only the current state of the entities. Some systems add explicit support for historical states with validity periods and/or bitemporal data.
Systems which are based on Event Sourcing store the sequence of events instead of entity state in a way that allows it to reconstruct the state from events. There is only one transactional resource to maintain - event store - so there is no need to coordinate transactions.
Other patterns in the list avoid the issue of transaction coordination by requiring the event producer code to commit all changes - both entities state and events (as entities) - to the single data store. Then a dedicated, but separate mechanism - event publisher - is implemented to fetch the events from the data store and publish them to the event consumers.
Event publisher would need to keep the track of published / unpublished events which usually brings back the problem of coordinated transactions. That's were the idempotency of the event consumers comes to light. Event publisher will replay events from the last known position while consumers will ignore duplicates.
You may also reverse the active / passive aspects of the event producer and event consumer. Event producer stores entities state and events (as entities) to the single data store and provides an endpoint which allows event consumer to access event streams. Each event consumer keeps track of processed / unprocessed events - which it needs to do anyway for idempotency reasons - but only for event streams it is interested about. A really good explanation of this approach is given in the book REST in Practice - chapters 7 and 8.
With SAGA you would like to split or reorder your transaction (tx) steps in 3 phases:
Tx steps for which you can have a compensating action. For each T1..N you have a
C1..N
Tx steps that cannot be compensating. If they fail then you trigger previously
defined C1..N
Retriable Tx steps that always succeed.
SAGAs are not ACID, only ACD. You need to implement yourself isolation, to prevent dirty reads. Usually with a locking.
Why SAGA? To avoid synchronous runtime coupling and pour availability. You wait for the last participant to commit.
It's quite a hefty price to pay.
The chance is small but still you can end up with inconsistent events that might be used to source an aggregate.
I have been asked to investigate some of our MDBs and where applicable move logic to an EJB. My question is does it matter if all the logic is in the OnMessage method or should this call an EJB method. The current logic does not need to be called directly so there is no need to make it accessible via an EJB. Would the MDB calling the EJB have any benefits?
The primary benefit of moving your logic to an EJB is that this will give you additional control over transaction boundaries.
As MDBs are inherently transactional, failures can result in a rollback followed by the message being re-delivered. Sometimes this is exactly the behaviour you want, but not often.
If you configure the service method on your EJB so that it starts a new transaction (REQUIRES_NEW) then any errors will result in a rollback of the EJB's transaction, but not that of the MDB.
The onMessage method can then take whatever action is required to recover (or not) within it's still intact transaction.
There is a difference between MDB and and EJB bean.
MDB is basically used for asynchronous processing where some system puts a message on the Queue and then Application server picks up an instance of MDB from the pool and process that message.
In case of EJB, its a synchronous call where client has to wait for the Application Server to respond.
So if you want to move your login into MDBs then check if the Asynhronous work which that MDB was doing is needed or not at all.
And instead of moving logic to EJB and calling that EJB , you can create an internal service class which will have the business logic and use this service from both the MDB and EJB implementation method.
So whichever way client wants it (asynchronous/synchronous), you can serve the same business logic.
An MDB can contain references to another EJB, JMS connection resources and any other datasource or database connection resources.
Other than that it should not hold any state (like a stateless bean not holding client state). MDBs are not accessed directly by clients, and no interface gets exposed, mdbs listen for messages asynchronously from clients.
So, check if the MDB instances retain any data or conversational state for a specific client.
Generally container should be able to assign a message to any one of the mdbs and also pool the instances, such that streams of messages from multiple clients can be processed concurrently. So separating concerns, as for any other class will have its benefit here as well, MDB should do what it is intended to do, move the business logic related to message handling to another EJB instance (if the contianer services are required).
The value of separation of concerns is simplifying development and
maintenance of computer programs. When concerns are well-separated,
individual sections can be reused, as well as developed and updated
independently. Of special value is the ability to later improve or
modify one section of code without having to know the details of other
sections, and without having to make corresponding changes to those
sections.
see wiki Separation of concerns. Separate class need be an ejb if u require the container services like transaction.
I find the similar question here but didn't find a clear answer on the transaction management for back end (database)
My current project is to create producer/consumer and let consumer to digest JMS message and persist in database. Because the back end of the application is managed by JPA, so it is critical to maintain the whole process transactional. My question is what is the downside if place #Transactional annotation on the classic onMessage method? Is there any potential performance challenge if do so?
The only problem may be if the whole queue process takes too long and the connection closes in the middle of the operation. Apart of this, if you enable the transaction for the whole queue process rather than per specific services methods, then theoretically the performance should be the same.
It would be better to enable two phase commit (also known as XA transaction) for each queue process. Then, define each specific service method as #Transactional and interact with your database as expected. At the end, the XA transaction will perform all the commits done by the #Transactional service methods. Note that using this approach does affect your performance.
This question follows directly from a previous question of mine in SO. I am still unable to grok the concept of JMS sessions being used as a transactional unit of work .
From the Java Message Service book :
The QueueConnection object is used to create a JMS Session object
(specifically, a Queue Session), which is the working thread and
transactional unit of work in JMS. Unlike JDBC, which requires a
connection for each transactional unit of work, JMS uses a single
connection and multiple Session objects. Typically, applications will
create single JMS Connection on application startup and maintain a
pool of Session objects for use whenever a message needs to be
produced or consumed.
I am unable to understand the meaning of the phrase transactional unit of work. A plain and simple explanation with an example is what I am looking for here.
A unit of work is something that must complete all or nothing. If it fails to complete it must be like it never happened.
In JTA parlance a unit of work consists of interactions with a transactional resource between a transaction.begin() call and a transaction.commit() call.
Lets say you define a unit of work that pulls a message of a source queue, inserts a record in a database, and puts the another message on a destination queue. In this scenario transaction aware resources are the two JMS queues and the database.
If a failure occurs after the database insert then a number of things must happen to achieve atomicity. The database commit must be rolled back so you don't have an orphaned record in the datasource and the message that was pulled off the source queue must be replaced.
The net out in this contrived scenario is that regardless of where a failure occurs in the unit of work the result is the exact state that you started in.
The key to remember about messaging systems is that a more global transaction can be composed of several smaller atomic transactional handoffs queue to queue.
Queue A -> Processing Agent -> Queue B --> Processing Agent --> Queue C
While in this scenario there isn't really a global transactional context(for instance rolling a failure in B->C all the way back to A) what you do have is garauntees that messages will either be delivered down the chain or remain in their source queues. This makes the system consistent at any instant. Exception states can be handled by creating error routes to achieve a more global state of consistency.
A series of messages of which all or none are processed/sent.
Session may be created as transacted. For a transacted session on session.commit() all messages which consumers of this session have received are committed, that is received messages are removed from their destinations (queues or topics) and messages that all producers of this session have sent become visible to other clients. On rollback received messages are returned back to their destinations, sent messages removed from destination. All sent / received messages until commit / rollback are one unit of work.
I am working on an EJB3 application with mainly stateless session beans (SLSB). They use container managed transactions (CMT).
I want the beans to be aware of the transactions (for logging, etc). I can implement the javax.ejb.SessionSynchronization to do this. I find that I can register a javax.transaction.Synchronization in a default interceptor also to get similar callbacks.
Are there any dis/advantages to using one over the other?
Multiple SLSB of the same type can be involved in the same transaction. As soon as a method exits, the SLSB is returned to a pool for use by the next invocation, so it is not safe for an SLSB instance to be "aware" of a transaction: by the time it is notified, the bean might be in use in another transaction.
As for SFSB, I would say there is no advantage between the two approaches in theory. However, the EJB container might be using Synchronization for various internal tasks, so using SessionSynchronization would allow the EJB container to have more control over the timing of the callbacks with respect to its own operations.
I just tried to use the javax.ejb.SessionSynchronization interface with a stateless session bean and was confused not to get any calls of the three implemented methods. Then I saw this comment in the javax.ejb.SessionSynchronization JavaDoc:
Only a stateful session bean with container-managed transaction demarcation can receive session synchronization notifications. Other bean types must not implement the SessionSynchronization interface or use the session synchronization annotations.
See also this thread for some more background. So my conclusion is that making stateless session beans transaction-aware using CMT can NOT be achieved with javax.ejb.SessionSynchronization.