Transaction management in JCA adapter is screwed up

[timfox]

I just took a look at the tx management code in the JCA adapter, and it looks just plain wrong in places.

JBMMessageHandler::onMessage.

Firstly it seems a transaction is *always* being started and committed/rolled back for *every* message. It's my understanding that this should only be done if the bean is using CMT and the transaction atttribute is Required.

For BMT or transaction attribute=NOT_SUPPORTED no transaction should be created.

Also

 if (activation.getActivationSpec().getAcknowledgeModeInt() == Session.SESSION_TRANSACTED || activation.getActivationSpec()
 .getAcknowledgeModeInt() == Session.CLIENT_ACKNOWLEDGE)
 {
 try
 {
 message.acknowledge();
 }
 catch (MessagingException e)
 {
 log.error("Failed to process message", e);
 }
 }

The above code is a nonsense, since a) it's illegal to use CLIENT_ACKNOWLEDGE in a MDB and b) if a session is transacted, message.acknowledge() does nothing anyway.

Also the code in JBMResourceAdapter::createSession seems just plain wrong - it seems to be creating XA sessions when ack mode = auto_ack !! ??

The specification "EJB core contracts and requirements" Chapter 5 should be read properly and the code in the adapter corrected.

[timfox]

https://jira.jboss.org/jira/browse/JBMESSAGING-1687

[timfox]

This is how I think the tx behaviour should be:

1) CMT, tx=NOT_SUPPORTED, local_optimisation = false:

MDB should be *non transacted* - it should use the ack mode as specified in the meta data

2) CMT, tx=NOT_SUPPORTED, local_optimisation = true

MDB should be *non transacted* - it should use the ack mode as specified in the meta data

3) CMT, REQUIRED, local_optimisation = false:

MDB should create a JTA tx *before delivery* and commit at completion of onMessage

4) CMT, REQUIRED, local_optimisation = true

MDB should create a *** local tx *** *before delivery* and commit at completion of onMessage

5) BMT, local_optimisation = false:

MDB should be *non transacted* - it should use the ack mode as specified in the meta data (unless a user transaction is started)

6) BMT, local_optimisation = true

MDB should be *non transacted* - it should use the ack mode as specified in the meta data (unless a user transaction is started)

[ataylor]

Ive implemented this with the following changes.

2) CMT, tx=NOT_SUPPORTED, local_optimisation = true

MDB should be *non transacted* - it should use the ack mode as specified in the meta data

Ive made this option so that it uses the a local tx, this is to allow the user to run with *only* a single local tx. see next.

4) CMT, REQUIRED, local_optimisation = true

MDB should create a *** local tx *** *before delivery* and commit at completion of onMessage

When 'REQUIRED' is chosen then the container will always create a global tx no matter what. This happens when the call is made to endpoint..onMessage(message) method (endpoint is a proxy and creates the tx before the actual call to the MDB's onMessage). This means that there would be a local proxy and a global proxy. I've left this configurable and i'll explain fully in the docs how local optimization works.

5) BMT, local_optimisation = false:

MDB should be *non transacted* - it should use the ack mode as specified in the meta data (unless a user transaction is started)

The ack mode is always used. The outcome of a user transaction when used in an MDB has no effect on the actual delivery.

6) BMT, local_optimisation = true

MDB should be *non transacted* - it should use the ack mode as specified in the meta data (unless a user transaction is started)

I've allowed the user to be able to use local tx's if they want. because of the reason mentioned for 5). This means that if an exception is thrown from inside the MDb the user can have the message redelivered.

[timfox]

Are you allowing Clebert's suggestion of batching too?

[ataylor]

yeah, I'm going to do that

[timfox]

Great, I noticed this task is marked as complete. Does that mean batching is done too?

If so, how is it configured?

[ataylor]

Great, I noticed this task is marked as complete. Does that mean batching is done too?

No, I've just posted separately on this.