> JBoss4 implements the integration using JCA1.5 MessageEndpoint > The ConnectionConsumer is no longer used. > You should consider JBoss4 alpha quality software.
And I do. However, that doesn't answer the question of retry behaviour for MDBs in 4.0. Basically will the implementation in 4.0 for singleton MDBs operate similiar to what we've already discussed here for the 3.2 series. > First, QueueBrowsers are not transactional objects. I know and agree. > > I don't quite get what you are trying to achieve, if I understand it > correctly, this isn't going to work (even ignoring my comment > about the > QueueBrowser). > > (A) tx1 processes message1 and commits a message to (B) > (B) tx2 processes that message > (A) tx3 tries to look at the message from the first step but it is > already gone > > ACID has nothing to say about this - it is three different > transactions. > It is just a plain old race condition. Does tx2 or tx3 run first, who > knows? > > You can search for previous discussions on XA commit semantics on this > list. > There is no MDB or MessageListener attached to the second queue (queue/B). I'm basically using the second JMS queue (queue/B) as a temporary object storage space. So the message posted to queue/B in the scenario I spelled out in my prior post would/should be on the queue when the second message from queue/A triggers. Apart of message2's business logic does a lookup (via a QueueBrowser) for the message that the message1 process posted on queue/B. Below is a simplified example. 1. Two messages sitting on queue/A 2. Singleton MDB attached to queue/A 3. Message1 triggers from queue/A 4. The MDB calls a CMT SSB that does some business logic one leg of which is a post of a new message to queue/B. 5. The stack returns back to the MDB successfully and the CMT commit process begins. 6. Message2 triggers from queue/A. 7. The MDB calls a different CMT SSB that looks up (using a QueueBrowser) on queue/B the data that message1 put on the queue. In the above scenario, the process triggered by message2 on queue/A doesn't always see the message posted on queue/B by message1's process. My observation is that in the case of a singleton MDB setup with a Session MaxSize greater then one, there seems to be a race condition since the Session used by message1 has now been freed allowing message2 to be triggered prior to the container actually finishing its work of committing all enlisted resources that message1's flow changed (including the post to queue/B). 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
