Connection handles transacted messages/acknowledgments

[ovidiu.feodorov]

Tim,

The latest patch (http://jira.jboss.com/jira/browse/JBMESSAGING-58) is making the ConnectionDelegate responsible with transacted message/acknowledgment delivery to the server, on behalf of its sessions. The method in question is sendTransaction().

Why did you choose to involve the connection in this, at all? A JMS transaction is always localized at session level. A session could keep its own transacted messages and acknowledgments in a decentralized manner and avoid concurrent access to a shared resource, which is the ResourceManager's transaction map.

We could probably even think to a way to keep transacted messages per-producer and transacted acknowledgments per-cosumer, and have Session to just initiate the commit/rollback.

On the server-side, the ServerConnectionDelegate handles the transaction (sendTransaction()) by sending messages to their destinations (sendMessage()) or acknowledging messages (acknowledge()). I don't think these methods belong here. Sending transacted messages/acknowledgments would be more naturally a job for the ServerSessionDelegate, or even for ServerProducerDelegate/ServerConsumerDelegate.

I could see the reason JBossMQ does that: because only the connection has access to the ServerIL, which physically sends stuff to the server. The current implementation uses the InvokerInterceptor, which is PER_VM, so it doesn't matter which delegate makes the server invocation.

[adrian.brock]

Why did you choose to involve the connection in this, at all? A JMS transaction is always localized at session level.
...
I could see the reason JBossMQ does that: because only the connection has access to the ServerIL, which physically sends stuff to the server.

There is more to it that when JTA (transaction interleaving) is involved.
You can have one session do some work in the transaction, then it leaves
the transaction. Later another session takes over.
The jms session(s) maybe involved in a different transactions when the XAResource
commit lifecycle is invoked.
This is why there is the notion of transaction state is separate from the session.

[ovidiu.feodorov]

I see. The connection delegate, or more precisely the ResourceManager's map acts as an aggregator for messages possibly coming from different sessions that joined the same transaction. This only applies to XASessions, though, but it's enough to justify the current design.