"timfox" wrote : | Looking at the messaging core code I couldn't see any way of telling a Receiver to deliver a bunch of messages as an atomic unit. My knowledge of the messaging core is approaching zero so I could be missing a trick here. |
The receive is not a part of the transaction state. You receive messages before you do commit/rollback. It is the message acknowledgements that need to be prepared/committed. ack prepare -> logically remove messages ack commit -> physically remove messages ack rollback -> reinstate logically remove messages Of course the 1PC optimization bypasses the prepare. anonymous wrote : | So my assumption is that it's up to the JMS facade to hold onto messages until commit for a transacted session. I guess the same applies for acknowledgements. | Correct, though the unacknowledged messages need be "rolled back" in the event of session.close without a commit/rollback or a client crash. This should be handled gracefully by the client, but the server needs to be able to step in to recover the unreliable client leaving things in a mess. It also needs to hold uncommitted sent messages. anonymous wrote : | On this assumption (which may well be wrong) I'm trying to work out where we hold the set of messages for the transaction, so we can send them on the commit. | In a map inside the XAResource. txid -> transaction state (sends/acks) txid could be the XID for JTA, otherwise it will be an internal transaction id anonymous wrote : | Advantage of 2) seems to be minimising network/inter JVM calls in the case the client and the server peer aren't in the same JVM. | The interceptor could be located on either the server or the client, depending upon how thick/thin you want the clients. anonymous wrote : | Also, how do we deal with running out of memory if a lot of messages are sent in a transacted session? | This is an advanced feature that requires monitoring memory and moving messages out of memory when required (replaced with a handle to the cache store location). See the JBossMQ implementation if you want details. This is one of the things that is actually well designed in that implementation. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3873830#3873830 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3873830 ------------------------------------------------------- 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 JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
