The JMS specification provides a model that outlines how a messaging system should behave in a transactional environment. In the JMS transactional model, message producers and message consumers never participate in a single distributed transaction. Instead, the JMS specification has its own loosely coupled transaction model, whereby each message producer or message consumer has its own private transactional session with the messaging system, such as FioranoMQ.
This is due to the inherent nature of applications using messaging to communicate in an asynchronous environment. Senders and receivers of messages are abstractly decoupled from each other. A receiver can not be available at the time the sender initiates a transaction. Thus, the sender has a contract with the JMS messaging system, which ensures messages produced within a transactional session are "committed" to the JMS messaging system in an all-or-nothing manner. Likewise, the receiver has another contract with the JMS provider ensuring all messages being consumed within a transactional session are received in an all-or-nothing manner.
FioranoMQ, being s standards based JMS server, implements the above-mentioned model to provide XA support in a Distributed Transaction environment using the JMS XA Service Provider Interface (JMS XA SPI).
In addition to the high performance "file based" data store, FioranoMQ supports the use of Relational Database (like Oracle) as message data stores.
Transactions with J2EE
J2EE Applications include components that take advantage of infrastructural services provided by the J2EE Container and Server, and therefore need only to focus on "Business logic".
Transactional support is an important infrastructural service offered by the J2EE platform. The specification describes the Java Transaction API (JTA), whose major interfaces include: javax.transaction, UserTransaction, and the javax.jms.TransactionManager. The UserTransaction remains exposed to application components, while the underlying interaction between the J2EE server and the JTA TransactionManager is transparent to the application components. The JTA UserTransaction and JDBC's transactional support are both available to J2EE components.
An EJB (Enterprise Java Bean) running in an Application Server exposes the business logic methods that clients invoke to perform useful operations, such as depositing or withdrawing from a bank account. Enterprise beans are capable of handling transactions. This implies that EJBs can fully leverage the ACID properties to perform reliable, robust server side operations. Thus, EJBs are ideal modules for performing mission critical transactional tasks.
In an EJB, the code never interacts with the low-level transactional system. The beans never interact with a transaction manager or a resource manager.
The application logic needs to be written at a high level, without regard for specific underlying transaction systems. The low-level transaction system is abstract to the EJB container that runs behind the scenes.
The bean components are responsible for deciding when a transaction should begin, commit or abort. If the system executes properly, a commit is invoked; else an abort is invoked.
It is the XAResource provider (FioranoMQ) responsibility to integrate itself seamlessly with the transaction in progress and allow for behind the scenes enlistment and delistment. Commit operations, with transaction propagation managed by the application server.
This provides a much higher level of abstraction as compared to using an external transaction manager. In addition, it achieves the objective of isolating the "business logic designer"/"bean designer" from the details of how the transaction progresses. The bean no longer has to take care of specific enlisting, delisting, and committing or rolling back transactions in progress. This is in contrast to controlling transactions using an external transaction Manager.
The javax.transaction.UserTransaction interface defines methods that allow applications to define transaction boundaries and explicitly manage transactions. The UserTransaction implementation provides application components – servlets, JSPs, EJBs (with bean-managed transactions) – with the ability to programmatically control transaction boundaries. EJB components can access UserTransaction through EJBContext using the getUserTransaction () method. Some of the methods specified in the UserTransaction interface include begin (), commit (), getStatus (), rollback () and setRollbackOnly (). The J2EE server provides the object that implements the javax.transaction.UserTransaction interface and makes it available through JNDI lookup.
FioranoMQ as an XAResource provider can be integrated with any J2EE application server so as to perform in a predictable manner when used with a UserTransaction object provided by the application server.