The original point was that JMS allows you transact the message put. If the message put is part of the global unit of work and it has not committed, then no receiver can pick up the message (the put does not actually occur till we commit). This really has VERY little to do with the fact the jms is asynchronous.
In all other respects you are correct. Regards, Hiram > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > fleury > Sent: Wednesday, January 15, 2003 6:37 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Transaction propagation change > > > one of my favorite topics is coming up again > One day I will sit down and write a tx spec. > > Ok frankly WHY DO WE CARE THAT MESSAGING IS ASYNCHRONOUS WITH RESPECT TO > TRANSACTION. Yeah I know the answer you could have a long running > transaction and messages and queues and bla bla bla. BS BS BS. > > So the method returns immediately. SO WHAT? the listener that will pick > up the message and act upon it may very well want to synchronize with > the GLOBAL transaction going on in the web. And commit or rollback > according to the outcome. > > The scenario is simple. > > Image A does something and sends messages to n instances with a global > transaction associated to it. > > n recievers get the message get the TPC and register with the global tx. > If the global tx is still running then all good 2phi dance starts bla > bla bla. if the tx is out (too old) then the guy who woke up late just > says "sorry can't register" and possibly no one cares or he can notify > (whatever the app rollback semantics are). > > AT A SYSTEM LEVEL I DON"T SEE A REASON FOR THIS "BAD IDEA" SYNDROME. IN > fact it always has struck me that there is NO WAY to propagate a TX with > a message. > > you know what? this is something we can VERY easily do in JBoss. Adding > the message in the new rewrite may be the usual 'put an interceptor > here' deal, once we make progress on the rewrite. > > But the point is simple, the asynchronous nature of the transport > protocol should not have an impact on the definition of a web > transaction. > > IN fact it is a requisite for web services (generic way)Tx definitions. > > Many threads TX! > > </water-walking> > > marcf > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]] On > > Behalf Of danch > > Sent: Wednesday, January 15, 2003 6:18 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] Transaction propagation change > > > > > > And having a way to do that would probably be a Bad Idea. > > Propogating a > > transaction through asynchronous transports doesn't sound like a good > > idea to me, anyway. > > > > -danch > > > > Hiram Chirino wrote: > > > Just a small correction.. your example would have to be in > > at least 2 > > > units of work. There is NO WAY to put a JMS message and > > get it again > > > in a single transaction. > > > > > > Regards, > > > Hiram > > > > > > > > >>Having a distributed transaction context is especially > > important for > > >>example when you have a EJB from one jboss instance posting > > a message > > >>to a JMS queue > > >>on another jboss instance that in turn has a MDB that calls > > another EJB on > > >>that second instance. If I want that all to be under one > > transaction and > > >>thus rollback as one business unit of work, there is no way to do > > >>that (that > > >>i'm aware of) with "native" JBoss in the 3.x series. I > > know one could use > > >>Tyrex, but the author doesn't recommend using Tyrex in a production > > >>environment and so I'm a little leary to use it myself. > > >> > > > > > > > > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: A Thawte Code Signing Certificate > > is essential in establishing user confidence by providing > > assurance of > > authenticity and code integrity. Download our Free Code > > Signing guide: > > http://ads.sourceforge.net/cgi-> bin/redirect.pl?thaw0028en > > > > > > _______________________________________________ > > Jboss-development mailing list [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: A Thawte Code Signing Certificate > is essential in establishing user confidence by providing assurance of > authenticity and code integrity. Download our Free Code Signing guide: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development ------------------------------------------------------- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
