> 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.
Well I think the crux of the problem is that there is no propagation of context with the JMS message. There is indeed a (weak) notion of transacting of sending and receiving but essentially your transactional scope ends at the start of async messages. Why ? Sorry if I focused on one aspect of the talk, it is a topic that has bothered me for about 3 years :), the web transaction is still in pampers and many people see it as the ugly duckling. marcf > > 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 > ------------------------------------------------------- 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
