Let me simplify the example to demonstrate my real point. (and hopefully this is a better example)
In the 3.x series of JBoss, there isn't a way to have one SSB with a transaction attribute of Required call another SSB with a transaction attribute of Required on a second jboss instance and have both of those beans enlist in any kind of "native" JBoss transaction. If you stay within one instance of JBoss, you are fine, but the moment you start to really do n-tier designs with tight transaction integration (ie XA), that is when problems arise with this NotSerializable exception. I do know that the 3.x series only supports local transaction, but my overall point is that I just don't understand why a distributed transaction has not been a "native" feature of JBoss from the beginning being that it seems to me that it would be fundamental to n-tier designs. I presume there is a good reason for this. I just don't know/see what that reason would be. If you have persistent JMS queues, then I would probably agree that having a distributed global transaction involved when asychronous transports are involved may not be best practice. However, if a non-persistent JMS queue is used (and i don't know why anyone wouldn't use persistence), then I can see having a distributed transaction as very beneficial to the integrity of a single unit of work. Dustin > -----Original Message----- > From: marc fleury [mailto:[EMAIL PROTECTED]] > 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
