Thanks Adrian, that's a lot clearer now. I've now moved the transaction handling logic into the interceptor stack.
So far, I've put it into TransactionInterceptor. TransactionInterceptor does the following: It intercepts ConnectionDelegate.createSessionDelegate() and creates a new local tx (using the local transaction manager) if the session is transacted. The Xid of this is then stored in the meta-data accessible to the SessionDelegate. It intercepts ProducerDelegate.send() and adds the message to a list of messages for the tx if the session is transacted. It intercepts SessionDelegate.commit() and sends the list of messages to the ServerSessionDelegate for passing to the messaging core for delivery. It also intercepts SessionDelegate.rollback() and SessionDelegate.close(); I noticed that there's also a SessionInterceptor in the design documents, but wasn't entirely sure what kind of stuff it has responsibility for. Perhaps some of the transacted session stuff needs to go in the SessionInterceptor? I'm not 100% sure of the split of responsibility between these interceptors. I could probably do with a steer here. -Tim View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3874143#3874143 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3874143 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ JBoss-Development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-development
