Adrian Brock wrote: >The order of work is roughly: > >1) receive() >2) getSession() and enlist in tx >3) getMDB() >4) onMessage() >5) releaseMDB() >6) commitSession()
Why couldn't the commitSession() be done prior to releaseMDB()? Seems that if 5 and 6 were flipped, the overall behaviour would be the same. Plus with a singleton MDB setup, one could take advantage of the read-ahead optimization by having MaxSize set to a value higher then one, and still have acidity of CMT between each MDB invocation of onMessage(). Otherwise, you basically have to choke off the pooling at the session level to keep the async behaviour of the MDB at bay until the session commits. Is it done that way because another transactable resource could be enlisted for which the session would have to commit after releaseMDB()? Even if the MDB itself calls a CMT SSB, the releaseMDB() would be presumably done after the releaseSSB(). IE: 1) receive() 2) getSession() and enlist in tx 3) getMDB() 4) onMessage() 5) invoke CMT method on SSB() 5) getSSB() and enlist in tx 6) run CMT method 7) releaseSSB() 8) releaseMDB() 9) commitSession() Dustin ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
