The fix of putting the transaction context in the transient_payload, as apposed to the as_is_payload. A while back I got Tyrex to somewhat work in the 3.2 series, but the only way I could get passed the NonSerializable exception was to change the code in org.jboss.invocation.Invocation.java to put the transaction context in the transient_payload. I was not very comfortable with this change being that I wasn't sure what the overall transaction integrity implications where for making the patch. I just followed the directions I found here http://www.mail-archive.com/[email protected]/msg21152.html and it got me past the error.
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. Plus the other fix that Scott described where RequiresNew is honored. Also, it would be useful to not propogate the transaction context to the receiver node if the caller is not apart of a container transaction (with a transaction semantic of NEVER in the ejb-jar.xml). Dustin > -----Original Message----- > From: David Jencks [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 13, 2003 9:37 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Transaction propagation change > > > > On Monday, January 13, 2003, at 08:58 AM, Barlow, Dustin wrote: > > > Will this fix also be back ported to the 3.x series as > well? This is > > a huge > > issue for those of us who are or plan to use more then one > jboss node > > in our > > applications. > > > Which fix? Not propagating anything is easy to port. Enabling > distributed transactions is a lot of work that is not all > done and may > not be easy to backport. I certainly don't want to try with 3.0, I > might consider 3.2. > > david jencks > > Dustin > > > >> -----Original Message----- > >> From: Scott M Stark [mailto:[EMAIL PROTECTED]] > >> Sent: Sunday, January 12, 2003 4:19 AM > >> To: [EMAIL PROTECTED] > >> Subject: [JBoss-dev] Transaction propagation change > >> > >> > >> Regarding bug: [ 663114 ] MarshallException when accessing > >> remote bean, this is > >> due to a change made to store the transaction context of an > >> Invocation in the as_is_payload > >> rather than the transient_payload map about the time of the > >> 3.0.0 release. Our tx > >> info never has been serializable, and the marshalled form of > >> the tpc is handled at the > >> MarshalledInvocation layer anyway rather than relying on the > >> correct form of the tx > >> context being placed into the Invocation. > >> > >> In the case of this particular bug, an EJB A on host 1 calls > >> an EJB B on host 2. Both > >> EJBs uses REQUIRED transaction attributes for all methods, so > >> according to the > >> EJB spec this call should actually fail since the expectation > >> a client can assume is that > >> the existing transaction context of EJB A will be propagated. > >> However, we fail all calls > >> regardless of the transaction attributes. If EJB B was using > >> RequiresNew the call should > >> succeed. > >> > >> I'm inclined to move the transaction context into the > >> transient_payload map to allow > >> valid calls to succeed. This does raise the possibility that > >> the application data can become > >> corrupted if it does expected distributed transaction > >> semantics on inter-server EJB calls. > >> > >> We need to cleanup the tx propagation so that its consistent > >> with the spec. Both for > >> the case of not supporting tx propagation and the case of > >> supporting it. Is this being > >> included in the 4.0 changes concerning the distributed > >> transaction support? > >> > >> xxxxxxxxxxxxxxxxxxxxxxxx > >> Scott Stark > >> Chief Technology Officer > >> JBoss Group, LLC > >> xxxxxxxxxxxxxxxxxxxxxxxx > >> > >> > >> ------------------------------------------------------- > >> This SF.NET email is sponsored by: > >> SourceForge Enterprise Edition + IBM + LinuxWorld = > Something 2 See! > >> http://www.vasoftware.com > >> _______________________________________________ > >> Jboss-development mailing list > >> [EMAIL PROTECTED] > >> https://lists.sourceforge.net/lists/listinfo/jboss-development > >> > > > > > > > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > > are you planning your Web Server Security? Click here to get a FREE > > Thawte SSL guide and find the answers to all your SSL > security issues. > > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: Take your first step > towards giving > your online business a competitive advantage. Test-drive a Thawte SSL > certificate - our easy online guide will show you how. Click > here to get > started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ------------------------------------------------------- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
