On Fri, 2003-08-15 at 16:38, Barlow, Dustin wrote: > Setting the MaximumSize to 1 does indeed fix the problem, or at least masks > it. > > Now, this begs the question of since there is a complete rewrite of JMS in > the 4.0 series, and I am planning to upgrade from the 3.2 series to 4 series > to utilize the new JBossDO implementation, will this same behaviour be in > the 4.0 series as well? >
JBoss4 implements the integration using JCA1.5 MessageEndpoint The ConnectionConsumer is no longer used. You should consider JBoss4 alpha quality software. > The second issue this brings up is transaction behaviour. > > I have a CMT MDB consuming on queue/A. The MDB fires and calls a CMT SSB > that subsequently pushes a message onto queue/B (JMS access done via a > ConnectionFactory gotten from java:/JmsXA). For sake of the example I have > two messages sitting on the queue. The first message is going to write to > queue/B, the second one is going to use a queue browser and lookup what the > message on queue/B that the first message coming from queue/A wrote. > > The behaviour I've witnessed is that when message one succeeds and goes into > the final commit stage of the CMT, message two actually fires prior to the > container transaction fully committing message one's work to queue/B. This > means that message two doesn't see the message on queue/B that message one > wrote to it. > > I presume this behaviour is also due to the ConnectionConsumer read-ahead > strategy? I was under the impression that if I have a singleton MDB, that > the second message on the queue would not be fired until the first message > is fully consumed, and any resources that message had altered would be fully > committed prior to the next message on the queue being consumed by the MDB. > It seems that the commit of the first message is happening async to the > consumption of the second message. Setting the MaximumSize on the > proxy-factory-config to 1 fixed/masked this scenario as well. > > I don't know what the spec has to say about the above scenario, but it seems > to me that if I want true acidity of resources in the case of a singleton > MDB setup, that the second message should not fire until message one had > been consumed and all resources that enlisted in the container transaction > should be actually commited so that message two could see them when it > fires. > First, QueueBrowsers are not transactional objects. 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. Regards, Adrian > 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
