Possible transaction scopes for asynchronous reception?

[chtimi2]

Producer-side, several messages can be grouped in a single transaction.

But consumer-side, is it possible to have (another) transaction span the consumption of the same set of messages?
What are the possible transaction scopes for asynchronous reception?

[ataylor]

I'm not sure i understand your question. when you say 'consumption of the same set of messages' do you mean from a topic. If so the each consumer can consumer the messages within its own transaction. The transaction covers the delivery of the messages not the message itself.

[gaohoward]

in JMS, the producer and consumer are separate. So you are free to define a transaction boundary for the messages regardless the producer side. don't quite understand your second question, can you explain it a bit more?

[chtimi2]

Sorry my question wasn't very clear.
I know that it isn't possible to produce and consume a message in the same transaction.

What i want to do is this:
If N messages have been produced in a single transaction T_prod, i want them to be consumed in a single transaction T_cons.
T_prod and T_cons don't have to be the same, i know that's not possible.

"ataylor" wrote:
I'm not sure i understand your question. when you say 'consumption of the same set of messages' do you mean from a topic.
If so the each consumer can consumer the messages within its own transaction. The transaction covers the delivery of the messages not the message itself.

Yes, i'm talking about a topic.
Let's say that the producer posts 2 messages, in a transaction (let's call it T_prod).

Let's say the consumer is a MDB: with Container Managed Transaction, each onMessage will execute in a new transaction, independant from T_prod.

What i'm wondering is whether it's possible, by using Bean Managed Transaction in the MDB, to get the 2 onMessage calls to execute within a single transaction.

I'm thinking of a pattern like this:
-Producer side: put the T_prod transaction id in the message header
-Consumer side: read the transaction id to determine if the message is the first to be recieved from T_prod, manually start and commit

[chtimi2]

"gaohoward" wrote:
in JMS, the producer and consumer are separate. So you are free to define a transaction boundary for the messages regardless the producer side.

Hopefully my answer to ataylor makes what i want to do a bit clearer.
I know it is possible to define the transaction boundary consumer-side (you need to use BMT in you MDB).
But since in my example the 2 onMessage executions would happen in a different thread, wouldn't it be impossible for them to happen in the same transaction?

"gaohoward" wrote:

don't quite understand your second question, can you explain it a bit more?

For instance can 2 onMessages (different threads) execute in a single transaction?

[ataylor]

Ok, i see what your asking, but it seems like a strange thing to try and acheive. Maybe your app architecture needs a rethink?

Any way with BMT its the container that creates the UserTransaction you have access to, you only commit or rollback, so each MDB instance would have its own transation. You could create your own tx but that wouldnt involve the delivery of the message which is i guess what you want. I would rethink what you want. p.s. all this is more to do with the App server than messaging per se, so maybe they would be ablt to help you more, but in trusth i would think of a different solution

[timfox]

"chtimi2" wrote:
Sorry my question wasn't very clear.
I know that it isn't possible to produce and consume a message in the same transaction.

What i want to do is this:
If N messages have been produced in a single transaction T_prod, i want them to be consumed in a single transaction T_cons.
T_prod and T_cons don't have to be the same, i know that's not possible.

"ataylor" wrote:
I'm not sure i understand your question. when you say 'consumption of the same set of messages' do you mean from a topic.
If so the each consumer can consumer the messages within its own transaction. The transaction covers the delivery of the messages not the message itself.

Yes, i'm talking about a topic.
Let's say that the producer posts 2 messages, in a transaction (let's call it T_prod).

Let's say the consumer is a MDB: with Container Managed Transaction, each onMessage will execute in a new transaction, independant from T_prod.

What i'm wondering is whether it's possible, by using Bean Managed Transaction in the MDB, to get the 2 onMessage calls to execute within a single transaction.

I'm thinking of a pattern like this:
-Producer side: put the T_prod transaction id in the message header
-Consumer side: read the transaction id to determine if the message is the first to be recieved from T_prod, manually start and commit

You cannot do this with MDBs, but you can do this with straight JMS consumers.

[chtimi2]

"ataylor" wrote:
Ok, i see what your asking, but it seems like a strange thing to try and acheive. Maybe your app architecture needs a rethink?

Well it is certainly not the most common use case, but i think it is meaningful:
- i need asynchronous, transactional notification
- the notification is still fire-and-forget producer-side
- the producer-side transaction scope still has a meaning consumer-side (the notification handling also needs to be ACID client-side). Imagine that the client-side handling also deals with transactional resources, we don't them to be left in an inconsistent state.

[chtimi2]

"timfox" wrote:

You cannot do this with MDBs, but you can do this with straight JMS consumers.

I'm not really using MDBs, but a Spring MDP. Are you saying this could work?
Isn't the real problem that the consumer is asynchronous?

[chtimi2]

Any idea? I get the feeling that the real problem is an incompatibility between asynchronicity and the propagation of the transaction context but it is an impossibility or something i'm unfamiliar with? And is this incompatibility specific to JMS or more general?

After all the transaction context is propagated to a different thread (from the client thread to the server thread) by rmi during a remote transactional invocation, so it doesn't have to be strictly thread-local.

On the other hand even in the EJB 3.1 spec, it is mentioned that for the new @Asynchronous methods, the transaction context will not be propagated from the caller to the callee.

[chtimi2]

The only solution i can think of is intercepting message production, to aggregate the messages produced within a transaction into a single wrapper message.
This way the consumption scope necessarily spans the same messages as the production scope.