io.mats3.impl.jms

Interface JmsMatsTransactionManager.TransactionContext

All Known Implementing Classes:

JmsMatsTransactionManager_Jms.TransactionalContext_Jms, JmsMatsTransactionManager_JmsAndJdbc.TransactionalContext_JmsAndJdbc

Enclosing interface:

JmsMatsTransactionManager

Functional Interface:

This is a functional interface and can therefore be used as the assignment target for a lambda expression or method reference.

@FunctionalInterface
public static interface JmsMatsTransactionManager.TransactionContext

Implementors shall do the transactional processing and handle any Throwable that comes out of the JmsMatsTransactionManager.ProcessingLambda by rolling back.

Method Summary

Modifier and Type	Method and Description
void	doTransaction(JmsMatsInternalExecutionContext jmsSessionMessageContext, JmsMatsTransactionManager.ProcessingLambda lambda) Shall open relevant transactions (that are not already opened by means of JMS's "always in transaction" for transactional Connections), perform the provided lambda, and then commit the transactions (including the JMS Session).

Method Detail

doTransaction

void doTransaction(JmsMatsInternalExecutionContext jmsSessionMessageContext,
                   JmsMatsTransactionManager.ProcessingLambda lambda)
            throws JmsMatsException.JmsMatsJmsException,
                   MatsEndpoint.MatsRefuseMessageException

Shall open relevant transactions (that are not already opened by means of JMS's "always in transaction" for transactional Connections), perform the provided lambda, and then commit the transactions (including the JMS Session).

If any Exception occurs when executing the provided lambda, then the transactions should be rolled back - but if it is the declared special MatsEndpoint.MatsRefuseMessageException, then the implementation should also try to ensure that the underlying JMS Message is not redelivered (no more retries), but instead put on the DLQ right away. (Beware of "sneaky throws": The JVM bytecode doesn't care whether a method declares an exception or not: It is possible to throw a checked exception form a method that doesn't declare it in several different ways. Groovy is nasty here (as effectively all Exceptions are unchecked in the Groovy world), and also google "sneakyThrows" for a way to do it using "pure java" that was invented with Generics.)

Parameters:

jmsSessionMessageContext - holds, amongst possibly other stuff, the JmsMatsJmsSessionHandler.JmsSessionHolder instance which contains the JMS Session upon which this transaction should run. Gotten from JmsMatsJmsSessionHandler.getSessionHolder(JmsMatsStageProcessor) or JmsMatsJmsSessionHandler.getSessionHolder(JmsMatsInitiator).

lambda - the stuff that shall be done within transaction, i.e. the MatsStage or the MatsInitiator.

Throws:

JmsMatsException.JmsMatsJmsException

MatsEndpoint.MatsRefuseMessageException