Package io.mats3.impl.jms

Class JmsMatsTransactionManager_Jms

java.lang.Object
io.mats3.impl.jms.JmsMatsTransactionManager_Jms
All Implemented Interfaces:
JmsMatsStatics, JmsMatsTransactionManager
Direct Known Subclasses:
JmsMatsTransactionManager_JmsAndJdbc, JmsMatsTransactionManager_JmsAndSpringManagedSqlTx
public class JmsMatsTransactionManager_Jms extends Object implements JmsMatsTransactionManager, JmsMatsStatics
Implementation of JmsMatsTransactionManager handling only JMS (getting Connections, and creating Sessions), doing all transactional handling "native", i.e. using only the JMS API (as opposed to e.g. using Spring and its transaction managers).

The JMS Connection and Session handling is performed in calling code, where the resulting JmsMatsJmsSessionHandler.JmsSessionHolder is provided to the JmsMatsTransactionManager_Jms.TransactionalContext_Jms.doTransaction(JmsMatsInternalExecutionContext, ProcessingLambda).

Note: Musing about the JmsMats transactional handling 6 years later (2021-02-03), I do find it a tad bit obscure. This entire Mats implementation is a JMS implementation, and all JMS Session handling is handled by the "core", but just exactly commit and rollback is handled in this class. The extensions handling SQL are much more "independent" as such. However, the big point is the JmsMatsStageProcessor, which has a JMS Consumer-pump/loop, and that Consumer's JMS Session is intimately intertwined with the transaction aspects handled here. Had it only been the JmsMatsInitiator and as such initiations of messages that should be handled, much more of the JMS transaction management could have been handled here. (Actually, the only transactional aspect at that point would have been to put a transaction around the actual sending, so that if more than one message was sent, they were all either sent or not.)