Re: [JBoss-dev] Transaction propagation change
On Tuesday, January 21, 2003, at 01:27 AM, marc fleury wrote: And, finally, why did you tightly couple distributed tx logic with invoker's implementation? Why is not it possible to write an interceptor that does distributed tx stuff that you've described but in invoker independent way? If only ole husgaard was awake :) I have been asking the same question for about a year and a half. I forgot the reason, which probably means it wasn't real, but Ole seemed to have one... I don't think there is a reason. I've been planning this for a couple months and discussed it at least once on this list. david marcf -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- 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: 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: 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
RE: [JBoss-dev] Transaction propagation change
Dunno yet, first I have to finish it:-) It uses the jca 1.5 interfaces pretty heavily, so it might be a fairly large change. However desirable it might be, realistically speaking, I probably won't backport it unless someone pays me. Fair enough. Maybe I can arrange to have you paid to do it. Dustin --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Transaction propagation change
On Tue, 21 Jan 2003, marc fleury wrote: And, finally, why did you tightly couple distributed tx logic with invoker's implementation? Why is not it possible to write an interceptor that does distributed tx stuff that you've described but in invoker independent way? If only ole husgaard was awake :) I have been asking the same question for about a year and a half. I forgot the reason, which probably means it wasn't real, but Ole seemed to have one... Transaction propagation over IIOP is a reason. CORBA specifies that transaction info goes in the service context, which is a field of the IIOP request. Francisco --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Transaction propagation change
On Tuesday, January 21, 2003, at 09:43 AM, Francisco Reverbel wrote: On Tue, 21 Jan 2003, marc fleury wrote: And, finally, why did you tightly couple distributed tx logic with invoker's implementation? Why is not it possible to write an interceptor that does distributed tx stuff that you've described but in invoker independent way? If only ole husgaard was awake :) I have been asking the same question for about a year and a half. I forgot the reason, which probably means it wasn't real, but Ole seemed to have one... Transaction propagation over IIOP is a reason. CORBA specifies that transaction info goes in the service context, which is a field of the IIOP request. Does this constrain non-iiop invokers in any way? Do we control anything about the client side of the iiop invoker? How about if the client is java rather than c++? Are there some short yet informative docs on how iiop into jboss works? thanks david jencks Francisco --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Transaction propagation change
On Tue, 21 Jan 2003, David Jencks wrote: On Tuesday, January 21, 2003, at 09:43 AM, Francisco Reverbel wrote: On Tue, 21 Jan 2003, marc fleury wrote: And, finally, why did you tightly couple distributed tx logic with invoker's implementation? Why is not it possible to write an interceptor that does distributed tx stuff that you've described but in invoker independent way? If only ole husgaard was awake :) I have been asking the same question for about a year and a half. I forgot the reason, which probably means it wasn't real, but Ole seemed to have one... Transaction propagation over IIOP is a reason. CORBA specifies that transaction info goes in the service context, which is a field of the IIOP request. Does this constrain non-iiop invokers in any way? I don't think so. Ideally it would be good if transaction propagation (i.e. all the code that inserts/extracts XIDs into/from invocation objects) were somehow encapsulated within a TxPropagator MBean, which would be specified by the contained configuration. Except for the IIOP invoker, all invokers would use the default TxPropagator MBean. The IIOP invoker would use an special tx propagator, which would insert/extract XIDs into/from IIOP service contexts. The idea of a default TxPropagator is similar to our ProxyFactory notion, in the sense that it works with all invokers but the IIOP invoker. The 3.2 container config includes a set of invoker/proxy bindings. Valid bindings are IIOPInvoker / IORFactory * / ProxyFactory (where * is any non-IIOP invoker) We could have invoker/proxy/txPropagator bindings instead: IIOPInvoker / IORFactory / IIOPTxPropagator * / ProxyFactory / TxPropagator Anyway, I don't think the IIOP case should constrain you from doing whatever needs to be done to have transactions propagated over non-IIOP protocols. Right now tx propagation over IIOP does not look like a prioritary thing, so I don't know if an IIOPTxPropagator will be written or not. Do we control anything about the client side of the iiop invoker? No. How about if the client is java rather than c++? In this case client-side stubs can (but are not required to) be dynamically downloaded from the server. Are there some short yet informative docs on how iiop into jboss works? No. I am planning to work on doco on February. Right now there is only the blurb in http://www.jboss.org/developers/projects/jboss/iiop.jsp, which applies to 3.0. (In 3.2 there were IIOP-related changes on the container config.) Do you have specific questions? Cheers, Francisco --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Transaction propagation change
On Tuesday, January 21, 2003, at 02:17 PM, Francisco Reverbel wrote: On Tue, 21 Jan 2003, David Jencks wrote: On Tuesday, January 21, 2003, at 09:43 AM, Francisco Reverbel wrote: On Tue, 21 Jan 2003, marc fleury wrote: And, finally, why did you tightly couple distributed tx logic with invoker's implementation? Why is not it possible to write an interceptor that does distributed tx stuff that you've described but in invoker independent way? If only ole husgaard was awake :) I have been asking the same question for about a year and a half. I forgot the reason, which probably means it wasn't real, but Ole seemed to have one... Transaction propagation over IIOP is a reason. CORBA specifies that transaction info goes in the service context, which is a field of the IIOP request. Does this constrain non-iiop invokers in any way? I don't think so. Ideally it would be good if transaction propagation (i.e. all the code that inserts/extracts XIDs into/from invocation objects) were somehow encapsulated within a TxPropagator MBean, which would be specified by the contained configuration. Except for the IIOP invoker, all invokers would use the default TxPropagator MBean. The IIOP invoker would use an special tx propagator, which would insert/extract XIDs into/from IIOP service contexts. The idea of a default TxPropagator is similar to our ProxyFactory notion, in the sense that it works with all invokers but the IIOP invoker. The 3.2 container config includes a set of invoker/proxy bindings. Valid bindings are IIOPInvoker / IORFactory * / ProxyFactory (where * is any non-IIOP invoker) We could have invoker/proxy/txPropagator bindings instead: IIOPInvoker / IORFactory / IIOPTxPropagator * / ProxyFactory / TxPropagator Anyway, I don't think the IIOP case should constrain you from doing whatever needs to be done to have transactions propagated over non-IIOP protocols. Right now tx propagation over IIOP does not look like a prioritary thing, so I don't know if an IIOPTxPropagator will be written or not. I want both client and server sides of the invoker (server side anyway for IIOP) to have interceptors. For non-IIOP the client side is basically an XAResource to turn the client-side tx into an xid for the remote server branch. This needs a more or less minimal client side tx manager and transaction implementation for clients that otherwise don't have a tm. The server side interceptor takes the xid and turns it into a transaction in the server tm. I suspect this is more or less identical to what you are suggesting. The only reason the trunk isn't like this yet is that I'm not sure what the AOP stuff will offer for configuring such a stack. Do we control anything about the client side of the iiop invoker? No. How about if the client is java rather than c++? In this case client-side stubs can (but are not required to) be dynamically downloaded from the server. Are there some short yet informative docs on how iiop into jboss works? No. I am planning to work on doco on February. Right now there is only the blurb in http://www.jboss.org/developers/projects/jboss/iiop.jsp, which applies to 3.0. (In 3.2 there were IIOP-related changes on the container config.) Do you have specific questions? Not yet, maybe after I look at it a bit. thanks david Cheers, Francisco --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Transaction propagation change
On Thursday, January 16, 2003, at 09:57 PM, Barlow, Dustin wrote: the only reason is that no one has previously written a distributed tx manager. I wrote the basic stuff we need in jboss 4, it should even work with the trunk invoker. david jencks Can this be back ported to the 3.x series? I'm mostly interested in the 3.2, but i presume it would also fit in 3.0 as well. Dunno yet, first I have to finish it:-) It uses the jca 1.5 interfaces pretty heavily, so it might be a fairly large change. However desirable it might be, realistically speaking, I probably won't backport it unless someone pays me. david jencks Dustin --- 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: 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
Re: [JBoss-dev] Transaction propagation change
On Sunday, January 19, 2003, at 10:00 AM, Igor Fedorenko wrote: David Jencks wrote: On Thursday, January 16, 2003, at 09:10 AM, Barlow, Dustin wrote: 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. the only reason is that no one has previously written a distributed tx manager. I wrote the basic stuff we need in jboss 4, it should even work with the trunk invoker. Can you describe this basic stuff a little? I am considering implementing distributed tx. I looked into the code and I have some implementation ideas in mind, but I would like to know what is your plan here and I definitely do not want to repeat something that is already done. So far it is only implemented for the trunk invoker, the others will be similar but I'm pressed for time and waiting for the AOP situation to clarify a bit. The invoker basically exposes itself to the client transaction manager as an XAResource, thus getting an xid branch for the tx on the remote server machine. This xid is transmitted in the invocation object, and imported into the remote server tm as a transaction, keeping the original global id part. remote server branches are created as usual. Then on prepare/commit, the xid is again transmitted using an invocation object, and finishes the remote branch using the XATerminator interface required by the jca 1.5 spec. So far I have only tested it a bit with UserTransactions, which now have a semi-functional tx manager on the client to provide xids. The next thing to do is to actually set up 2 servers and test whether it works. After it does, then I'll extend it to the other invokers. david -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- 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: 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
Re: [JBoss-dev] Transaction propagation change
David Jencks wrote: On Sunday, January 19, 2003, at 10:00 AM, Igor Fedorenko wrote: David Jencks wrote: On Thursday, January 16, 2003, at 09:10 AM, Barlow, Dustin wrote: 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. the only reason is that no one has previously written a distributed tx manager. I wrote the basic stuff we need in jboss 4, it should even work with the trunk invoker. Can you describe this basic stuff a little? I am considering implementing distributed tx. I looked into the code and I have some implementation ideas in mind, but I would like to know what is your plan here and I definitely do not want to repeat something that is already done. So far it is only implemented for the trunk invoker, the others will be similar but I'm pressed for time and waiting for the AOP situation to clarify a bit. The invoker basically exposes itself to the client transaction manager as an XAResource, thus getting an xid branch for the tx on the remote server machine. This xid is transmitted in the invocation object, and imported into the remote server tm as a transaction, keeping the original global id part. remote server branches are created as usual. Then on prepare/commit, the xid is again transmitted using an invocation object, and finishes the remote branch using the XATerminator interface required by the jca 1.5 spec. So far I have only tested it a bit with UserTransactions, which now have a semi-functional tx manager on the client to provide xids. The next thing to do is to actually set up 2 servers and test whether it works. After it does, then I'll extend it to the other invokers. Thank you for your explanation, David. Ive looked into the code and have few more questions, if you do not mind. Nothing seems to guarantee uniqueness of branch ids in parent and child transactions. Both of them start from the same branch id (zero) and thus generate same Xids. Entire Xid should be propagated to a remote node, and branch id should be generated by upending additional digits (resulting branch id will look something like parentBranch/subordinateBranch). How do you deal with loops? For example, node A starts a transaction, calls node B which calls node A back. From what I see, transactions on the two nodes will cross-reference each other making calls to commit/rollback deadlock. There is another flavour of this problem node A calls node C, then calls node B which calls node C. As a result, transaction on node C will be prepared/committed/rolledback twice. Ideally, only new subordinate transactions should be enlisted into a parent, in other words if a transaction re-enters a node nothing should be enlisted to make sure there are no loops. Subordinate transaction gets started regardless whether it is actually used on remote node or not. For example, if node A calls into transaction=RequiresNew method on node B an empty subordinate tx will be started causing unnecessary network traffic at commit time. Is there anything that prevents calling commit on subordinate transactions? Not a big deal, just for completeness sake ;-) And, finally, why did you tightly couple distributed tx logic with invokers implementation? Why is not it possible to write an interceptor that does distributed tx stuff that youve described but in invoker independent way? -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- 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
RE: [JBoss-dev] Transaction propagation change
And, finally, why did you tightly couple distributed tx logic with invoker's implementation? Why is not it possible to write an interceptor that does distributed tx stuff that you've described but in invoker independent way? If only ole husgaard was awake :) I have been asking the same question for about a year and a half. I forgot the reason, which probably means it wasn't real, but Ole seemed to have one... marcf -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- 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: 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
Re: [JBoss-dev] Transaction propagation change
David Jencks wrote: On Thursday, January 16, 2003, at 09:10 AM, Barlow, Dustin wrote: 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. the only reason is that no one has previously written a distributed tx manager. I wrote the basic stuff we need in jboss 4, it should even work with the trunk invoker. Can you describe this basic stuff a little? I am considering implementing distributed tx. I looked into the code and I have some implementation ideas in mind, but I would like to know what is your plan here and I definitely do not want to repeat something that is already done. -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- 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
RE: [JBoss-dev] Transaction propagation change
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 DONT 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
Re: [JBoss-dev] Transaction propagation change
I think you are confusing two things, marc. 1. multiple threads in one tx. This is doable technically and may produce determinate results if all threads access only different resource managers. If any access the same resource manager, you will easily get indeterminate results (e.g. one thread adds 2, the other thread mulitplies by 10, you start with 1, you can get 30 or 12 depending on order). This is not messaging in any sense I can think of. 2. transactional messaging. Basically the only idea here is commit a message to a queue/topic and it is guaranteed to be eventually delivered. Trying to make the transaction go with the message doesn't make any sense to me. There is no point in using messaging if you do this. Just start lots of threads, as in (1). Thinking about it more, I think you could get each message branch to prepare or rollback its work unilaterally when it finishes, but I think it would then have to inform the master tm of its vote. I don't see any way to eliminate the master tm having to send a final commit message to all the parties. I think this might eliminate one round trip call from branch to tm compared to (1) (the i'm done with this method call from branch to master and the prepare call from master to branch would be eliminated). I'm not sure the messaging part of this adds anything. We could do the same thing with just threads much more easily. If you think doing an optimization specifically with messaging like this adds something useful please provide a concrete example. Is this what you had in mind? Is it really worth doing? thanks david jencks On Wednesday, January 15, 2003, at 06:37 PM, marc fleury wrote: 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 DONT 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
RE: [JBoss-dev] Transaction propagation change
1. multiple threads in one tx. This is doable technically and may produce determinate results if all threads access only different resource managers. If any access the same resource manager, you will easily get indeterminate results (e.g. one thread adds 2, the other thread mulitplies by 10, you start with 1, you can get 30 or 12 depending on order). This is not messaging in any sense I can think of. But to do this you need a way to create a thread in a transaction-friendly way i.e. if you simply create a new thread (t = new Thread), then new correct transactional context is associated with this newly started thread. Correct? Cheers, sacha --- 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
RE: [JBoss-dev] Transaction propagation change
I think you're talking about giving people something more like asynchronous method invocations (one-way) than traditional MOM style messages, right? I am talking about propagation of TX with async calls, yes. An asynch. invocation on the other hand, ought to take the transaction with it, but I think you want a different programming model than the JMS overhead crap (look up three object in JNDI, call three factories, sacrifies three virgin goats...) I wouldn't care if it were LOL implemented on the same infrastructure as JBossMQ, but I'd really want a more light-weight programming model - like an asynchronous Aspect for the target object, or something... Yes lite-version of the specs would be a powerful thing to have, keep an eye open when we are done with the basic AOP framework. marcf --- 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
RE: [JBoss-dev] Transaction propagation change
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 DONT 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
RE: [JBoss-dev] Transaction propagation change
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Sacha Labourey Sent: Thursday, January 16, 2003 9:27 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Transaction propagation change 1. multiple threads in one tx. This is doable technically and may produce determinate results if all threads access only different resource managers. If any access the same resource manager, you will easily get indeterminate results (e.g. one thread adds 2, the other thread mulitplies by 10, you start with 1, you can get 30 or 12 depending on order). This is not messaging in any sense I can think of. But to do this you need a way to create a thread in a transaction-friendly way i.e. if you simply create a new thread (t = new Thread), then new correct transactional context is associated with this newly started thread. Correct? inheritableThreadLocal (or something like that) marcf Cheers, sacha --- 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
RE: [JBoss-dev] Transaction propagation change
1. multiple threads in one tx. This is doable technically and may produce determinate results if all threads access only different resource managers. If any access the same resource manager, you will easily get indeterminate results (e.g. one thread adds 2, the other thread mulitplies by 10, you start with 1, you can get 30 or 12 depending on order). This is not messaging in any sense I can think of. Order within a Transaction for correctness is not a design goal of transaction. Ordering of operations is a programmatic problem. I wouldn't ruse transactions to do that. I use transactions ON THE WEB to coordinate components. When there are many threads doing work a way to synchronize the work is with the 'commit' notifications from the 'orchestrator'. Ordering is an orthogonal issue. I'm not sure the messaging part of this adds anything. We could do the same thing with just threads much more easily. If you think doing an optimization specifically with messaging like this adds something useful please provide a concrete example. My point is that the transactional scope ends at the message layer (besides the enrollment in sending and receiving) and I don't see a fundamental reason for it. Why can't I think of my application critical unit as containing messages? essentially J2EE restricts me to designing critical sections WITHOUT messaging. For me the transaction (we are way passed the DB notion of it) is a higher level construct that visually isolates components and flows of the application under TX scope so their effect can be rolledback/synchronized. It is also a SIMPLER notion. I don't grock why a message or async call in general shouldn't be capable of propagating TPC. Concrete example. Buy book == debit credit card + send book. Both sub operations are triggered by MDB or message in general. TM knows there are 2 component to the transaction, does 2phi dance when both are registered. The fact that there is a message in the middle is it relevant? You ask if it is worth doing. I say I am in 'theory land' so probably not. The designs of the TM need to change a bit, meaning for example that the application needs to delegate synchronizatio to the TM and say there should be 2 components to this application (2 synchronizations registered) if not then you can rollback on timeout. But as soon as both are registered and I tell commit go ahead. marcf --- 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
RE: [JBoss-dev] Transaction propagation change
But to do this you need a way to create a thread in a transaction-friendly way i.e. if you simply create a new thread (t = new Thread), then new correct transactional context is associated with this newly started thread. Correct? inheritableThreadLocal (or something like that) Yes, but I meant that there is no standard way to do that i.e. what is missing is a way, in any app server or transactional-aware software, to use an API and say I want a thread that participates in my current transaction. For many app server, inheritableThreadLocal may be enough, for other not. Furthermore, by using ITL you bypass the thread pool. I guess it simply comes down to the fact that since the beginning we hear in specs: threads are bad, bouh! , thus it has never been standardized and instead we have to use 3000 lines of JMS + MDB to simulate async behaviour in containers. I guess this is the whole point: current JMS transactional behaviour is fine as long as what you want is *really* to decouple the producer from the consumer, but when what you want is just transactional multithreaded, then it is no more (and by far) a good solution because you end up using JMS+MDB for *nothing* --- 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
Re: [JBoss-dev] Transaction propagation change
I think you are confusing two things, marc. 1. multiple threads in one tx. This is doable technically and may produce determinate results if all threads access only different resource managers. If any access the same resource manager, you will easily get indeterminate results (e.g. one thread adds 2, the other thread mulitplies by 10, you start with 1, you can get 30 or 12 depending on order). This is not messaging in any sense I can think of. 2. transactional messaging. Basically the only idea here is commit a message to a queue/topic and it is guaranteed to be eventually delivered. Trying to make the transaction go with the message doesn't make any sense to me. There is no point in using messaging if you do this. Just start lots of threads, as in (1). Thinking about it more, I think you could get each message branch to prepare or rollback its work unilaterally when it finishes, but I think it would then have to inform the master tm of its vote. I don't see any way to eliminate the master tm having to send a final commit message to all the parties. I think this might eliminate one round trip call from branch to tm compared to (1) (the i'm done with this method call from branch to master and the prepare call from master to branch would be eliminated). I'm not sure the messaging part of this adds anything. We could do the same thing with just threads much more easily. If you think doing an optimization specifically with messaging like this adds something useful please provide a concrete example. Is this what you had in mind? Is it really worth doing? thanks david jencks On Wednesday, January 15, 2003, at 06:37 PM, marc fleury wrote: 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 DONT 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
RE: [JBoss-dev] Transaction propagation change
Dustin, I am sorry I went on a tangent, it is just a pet peeve of mine for the longest time (and I still have to hear about OLE, who likes these discussions ;). 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. Colocate! colocate! colocate! if you have a REAL reason for not colocate let's hear it. That has to do with the lack of distributed TM. Period. 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), By design and choice yes. 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. That is easy. SPEED. Distributed transaction are pricey and difficult. By choice we did fastTM as an InVM implementation. Typical case of 90/10. Most applications actually use only invm stuff and so having an implemetnation that serializes stuff back and forth isn't worth it. Right now FastTM is REALLY FAST, so that the overhead of synchronization is NIL (dozen or so native java method calls). It is one of these things where we said you really need DTM, write it or use tyrex. Turns out Tyrex was a fake with critical methods throwing NotImplementException. But clearly we didn't BASE the design on distribution. That being said 2 point: 1- even the EJB spec writers do research on invm tm. 2- we are writing parts of a real DTM. Please help. 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. That is what I contest. Why ? So what if it is persistent/async? theoretically speaking what is the limitation here? marcf --- 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
RE: [JBoss-dev] Transaction propagation change
guess it simply comes down to the fact that since the beginning we hear in specs: threads are bad, bouh! , thus it has never been standardized and instead we have to use 3000 lines of JMS + MDB to simulate async behaviour in containers. well what you want is a language level construct a la corba where a method can be said ONE-WAY. In fact we could TOTALLY do that on the new AOP framework. If you define with an xdoclet tag that a given method is @jboss:one-way then we put an interceptor that takes fresh thread and returns immediately. Me likes. The question of how we do it is secondary, either we go purely threadLocal (a hack) or we rely on the invocation' which should contain most of the data, Adrian pointed out in the forums that we need to do some more leg work on putting data in the invocation, but in any case. Associating the data with the thread one way or the other is easy. I guess this is the whole point: current JMS transactional behaviour is fine as long as what you want is *really* to decouple the producer from the consumer, but when what you want is just transactional multithreaded, then it is no more (and by far) a good solution because you end up using JMS+MDB for *nothing* right, it is a good point. The transactional part is lost. A simpler way is that there is NO propagation of TX context across async today and we could somewhat easily do it. DTM is still missing from the picture :) marcf --- 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
RE: [JBoss-dev] Transaction propagation change
In fact we could TOTALLY do that on the new AOP framework. If you define with an xdoclet tag that a given method is @jboss:one-way then we put an interceptor that takes fresh thread and returns immediately. Me likes. Please check out the metadata stuff I've been doing for the AOP framework. The question of how we do it is secondary, either we go purely threadLocal (a hack) or we rely on the invocation' which should contain most of the data, Adrian pointed out in the forums that we need to do some more leg work on putting data in the invocation, but in any case. Associating the data with the thread one way or the other is easy. I have metadata chains defined. Metadata is found in the following ways. ThreadLocal-Instance-Method-Class-Default Again, please see my configuration and metadata thread on the AOP forum. It may be applicable to this conversation. Bill --- 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
Re: [JBoss-dev] Transaction propagation change
Sacha Labourey wrote: + I guess this is the whole point: current JMS transactional behaviour is fine as long as what you want is *really* to decouple the producer from the consumer, but when what you want is just transactional multithreaded, then it is no more (and by far) a good solution because you end up using JMS+MDB for *nothing* Exactly! And what you want for multithread transactions is a cleaner API that lets you just say 'this method in this class should be run in a separate thread' and let the server manage the thread pool while you manage your application code. Get rid of the JMS hullabaloo for this purpose - it's designed for a different purpose. Also, don't make the application coders worry about creating a thread, just provide an aspecty-type thing so that I can plug it all together. -danch --- 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
RE: [JBoss-dev] Transaction propagation change
My answers/comments are inline: I am sorry I went on a tangent, it is just a pet peeve of mine for the longest time (and I still have to hear about OLE, who likes these discussions ;). No need to apologize at all. I think it's an interesting topic as well. Plus you're the boss so :) 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. Colocate! colocate! colocate! if you have a REAL reason for not colocate let's hear it. That has to do with the lack of distributed TM. Period. I am arguing for co-locating, so i take it that your challenge for reasons *not* to co-locate is not directed at me. Load balancing is one reason *for* co-locating. Lets say I want to run multiple instances of JBoss on separate iron(s) for performance reasons. One instance that simply does all the persistence for my application with synchronous session facades (or perhaps async MDB based dispatchers) in front of entity beans. Then I have another node that does all the business logic/presentation logic in SSB's. Then maybe a third for the front end (jsp's, servlets, ssb's etc). How would I inforce ACID semantics in this setup if local only transactions are the only option? That is easy. SPEED. Distributed transaction are pricey and difficult. By choice we did fastTM as an InVM implementation. Typical case of 90/10. Most applications actually use only invm stuff and so having an implemetnation that serializes stuff back and forth isn't worth it. Right now FastTM is REALLY FAST, so that the overhead of synchronization is NIL (dozen or so native java method calls). It is one of these things where we said you really need DTM, write it or use tyrex. Turns out Tyrex was a fake with critical methods throwing NotImplementException. But clearly we didn't BASE the design on distribution. I completely agree in terms of the speed aspect, however, shouldn't JBoss still have the option/ability of doing distributed transactions being that it is fundamental to a ACID n-tier based system? How are transactions handled today with clustering? If a clustered node goes down, can JBoss seemlessly pick up the pieces and move forward with a transaction or a separate node, or does it just bail out and rollback the entire thing? The major rub is that I can't even make a ejb to ejb call between two different jboss instances because it is trying to push the transaction context across the nodes, when the infrastructure doesn't support it (even if I have a transaction attribute of NEVER on both ejbs). I think this is exactly what Scott was addressing in his original post, that at a bare minium, we should have the ability to say, we don't want and can't have the transaction context pushed to the node, so don't even try. Of course this does opens up other issues as far as other beans involved in the container transaction and how they would be notified if the remote call fails. I presume this would have to be handled with tradition exception handling in the bean that actually makes the call to the remote node and it's job would be to mark the container transaction. Another scenario is a MDB deployed in one instance that is using a custom remote DestinationManager pointing to a JMS queue on a second JBoss instance (which currently doesn't work in 3.x .. but i'll leave that for another thread). How is the transaction handled in that scenario? If you say, just put the MDB on the other instance that houses the JMS queue and move to a push model instead of pull, then the problem I described above comes into play. The MDB tries to push it's transaction context to the second node, and fails. So the only way to do it is for the MDB to be BMT which means I now don't have the ability to use the message retry part of JMS. I have to write the code that handles failures, instead of letting the container do what it was designed to do. That being said 2 point: 1- even the EJB spec writers do research on invm tm. 2- we are writing parts of a real DTM. Please help. I've read posts from Jencks and co. and it appears that a DTM is in the works for 4.x. So maybe this whole topic is a mute point. But, it could be (possibly) another year or more before 4.x is ready for production use as well, so that is why i originally asked if there was the ability to port this new feature to the 3.x series. 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. That is what I contest. Why ? So what if it is persistent/async? theoretically speaking what is the limitation here? I think the argument is that because you have persistence you are guaranteed message
Re: [JBoss-dev] Transaction propagation change
If I understand you right, you're asking to propagate transactions via JMS messages because they're not propagated via non-local EJB calls. I think that begs the question, doesn't it? Meanwhile the conversation has gone on to (basically) asynchronous EJB (really AOP) calls. Barlow, Dustin wrote: 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), tight integration implies high coupling, which implies that they ought to be co-located. If the two components are loosely coupled, then you should be able to design it in the old fashioned MOM style, where transaction propagation isn't needed. 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. Distributed TX is more expensive - the JBoss TM is intended (currently) to be light-weight and quick rather than XA complete. 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. Except that you're using a very heavyweight, MOM-style API when what you wanted was just correct transaction behavior. --- 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
Re: [JBoss-dev] Transaction propagation change
marc fleury wrote: 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. No the crux of the problem is that JMS was designed to address the needs of providers of application integration infrastructure that's used for loosely coupled interfaces between systems. If you're loosely coupled enough to use JMS, you don't want the transaction propagated. 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 ? Well, really it also ends at the start of 'synchronous' messages as well, if you're foolish enough to do put synchronous semantics over the top of JMS/MOM. It's all because what we're talking about just doesn't make sense in a messaging integration type use case, where JMS/MOM makes sense. You're proposing something altogether different, more akin to a one-way from CORBA land. That's great, I love it, but referring back to how JMS does it is just confusing the issue. -danch --- 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
Re: [JBoss-dev] Transaction propagation change
Barlow, Dustin wrote: That is what I contest. Why ? So what if it is persistent/async? theoretically speaking what is the limitation here? because if you care about the transaction, JMS is the wrong tool. There's no theoretical limitation, but if what you want to to execute an asynchrounous task in the same transaction, why would you go through all of the JMS crap that's designed for a 'fire and profess apathy' sort of exchange. You want a tightly coupled transaction: why would you use an API that assumes the loosest of all possible couplings? Answer: only because marcf hadn't written the one-way spec yet! ;^}) I think the argument is that because you have persistence you are guaranteed message delivery even if the node dies. So once a message is successfully posted to the queue, stack returns to the caller (ie async) the transaction with the queue is technically done where the caller is concerned. With persistence, if the instance craters out before the message is succesfully consumed, then you should still have the message persisted and it would be picked back up and redispatched when the instance is brought back up thus protecting the original intent of the original poster's transaction. Yes! If that's not the behavior you want, you shouldn't be using persistent messaging. The originating caller can then be notified later on (if needed) once the JMS based message is consumed and processed successfully by, for example, posting back to a JMS queue on the caller's instance. Basically a workflow style system. exactly. that's what MOM systems are for. -danch --- 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
Re: [JBoss-dev] Transaction propagation change
Dustin, Please don't take offense here, but you seem to be heading in a couple of directions where, based on my experience, I think you'll hit some problems. Apologies in advance if I've misunderstood. Barlow, Dustin wrote: My answers/comments are inline: I am sorry I went on a tangent, it is just a pet peeve of mine for the longest time (and I still have to hear about OLE, who likes these discussions ;). No need to apologize at all. I think it's an interesting topic as well. Plus you're the boss so :) 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. Colocate! colocate! colocate! if you have a REAL reason for not colocate let's hear it. That has to do with the lack of distributed TM. Period. I am arguing for co-locating, so i take it that your challenge for reasons *not* to co-locate is not directed at me. I think you're arguing against colocating here, unless I'm missunderstanding dramatically. Load balancing is one reason *for* co-locating. Lets say I want to run multiple instances of JBoss on separate iron(s) for performance reasons. One instance that simply does all the persistence for my application with synchronous session facades (or perhaps async MDB based dispatchers) in front of entity beans. two points: 1. separating things out this way is very likely to hurt your performance. If you want performance, you should have the whole stack in the same process. If you want scalability, load-balance the whole application vertically, not horizontally. Yeah that's not what leaps to mind when they (we, speaking as one of they) say 'N-Tier', but it's what works. 2. (async base MDB dispatchers) You're not proposing doing a request/reply to an MDB, are you? That's taking an asynch. transport (NOTHING TO DO WITH TRANSACTIONS HERE!) and simulating a synchronous call over it. That tends to perform badly, you'll have some complex code to manage it, and I've found it to generally be a bad idea. The more typical need for distributed TX involves one application (A) that needs to make a request to another application (B), where A needs to know the result of the request (making synchronous the prefered invocation style) and a roll-back in either A or B needs to roll-back the both thing. The only time it makes sense to use JMS/MOM is when the requestor (A in my meta-example) doesn't really care what happens, AND where a rollback in B won't matter to A. Note that if A rolls back, the message will never be delivered. This is basically a case of A wanting to say Oh, if anybody cares, this happened. Extreme decoupling. The error handling on B's side tends to get a little hairy in these cases: it may need to intelligently recover from some errors, others can be retried at a later point, and for some errors it will wind up deffering to certain wet, grey, bio-electrical analog computers for resolution. Oh, the other time MOM makes sense is when one or more applications need to be integrated and they're entirely ignorant not only of one another, but of distributed transactions, Java, and the modern world in general. But hey, it keeps me busy! snip! Another scenario is a MDB deployed in one instance that is using a custom remote DestinationManager pointing to a JMS queue on a second JBoss instance (which currently doesn't work in 3.x .. but i'll leave that for another thread). How is the transaction handled in that scenario? The transaction is between the queue and the MDB - the ack for the message should be sent to the queue iff the MDB's transaction commits. The transaction started for the MDB's processing of the message is the only transaction in this scenario. What's the question, other than 'this doesn't work in 3.x.' It should. -danch --- 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
RE: [JBoss-dev] Transaction propagation change
I guess this is the whole point: current JMS transactional behaviour is fine as long as what you want is *really* to decouple the producer from the consumer, but when what you want is just transactional multithreaded, then it is no more (and by far) a good solution because you end up using JMS+MDB for *nothing* Exactly! And what you want for multithread transactions is a cleaner API that lets you just say 'this method in this class should be run in a separate thread' and let the server manage the thread pool while you manage your application code. Get rid of the JMS hullabaloo for this purpose - it's designed for a different purpose. Also, don't make the application coders worry about creating a thread, just provide an aspecty-type thing so that I can plug it all together. OK then that is the AOP thread interceptor with one-way tags, marcf -danch --- 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
RE: [JBoss-dev] Transaction propagation change
transaction attribute of NEVER on both ejbs). I think this is exactly what Scott was addressing in his original post, that at a bare minium, we should have the ability to say, we don't want and can't have the transaction context pushed to the node, so don't even try. Of course this does opens up agreed, marcf --- 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
RE: [JBoss-dev] Transaction propagation change
No the crux of the problem is that JMS was designed to address the needs of providers of application integration infrastructure that's used for loosely coupled interfaces between systems. If you're loosely coupled enough to use JMS, you don't want the transaction propagated. it is a point. marcf --- 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
Re: [JBoss-dev] Transaction propagation change
On Thursday, January 16, 2003, at 09:27 AM, Sacha Labourey wrote: 1. multiple threads in one tx. This is doable technically and may produce determinate results if all threads access only different resource managers. If any access the same resource manager, you will easily get indeterminate results (e.g. one thread adds 2, the other thread mulitplies by 10, you start with 1, you can get 30 or 12 depending on order). This is not messaging in any sense I can think of. But to do this you need a way to create a thread in a transaction-friendly way i.e. if you simply create a new thread (t = new Thread), then new correct transactional context is associated with this newly started thread. Correct? Exactly, this is the doable technically part. I don't think creating new threads directly is the way to go, but getting threads from a pool or factory. The Work contracts allow you to supply an xid, but prohibit more than one thread/tx. In one vm, we want to use a tx directly and allow lots of threads. I think we can use a different ExecutionContext-like object for this. We also need to pass the security context etc. david Cheers, sacha --- 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
Re: [JBoss-dev] Transaction propagation change
On Thursday, January 16, 2003, at 09:10 AM, Barlow, Dustin wrote: 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. the only reason is that no one has previously written a distributed tx manager. I wrote the basic stuff we need in jboss 4, it should even work with the trunk invoker. david jencks 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 DONT 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
RE: [JBoss-dev] Transaction propagation change
the only reason is that no one has previously written a distributed tx it is not the ONLY reason, but yes it is the REAL one. marcf manager. I wrote the basic stuff we need in jboss 4, it should even work with the trunk invoker. david jencks 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 DONT 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
Re: [JBoss-dev] Transaction propagation change
That is easy. SPEED. Distributed transaction are pricey and difficult. By choice we did fastTM as an InVM implementation. Typical case of 90/10. Most applications actually use only invm stuff and so having an implemetnation that serializes stuff back and forth isn't worth it. Right now FastTM is REALLY FAST, so that the overhead of synchronization is NIL (dozen or so native java method calls). It is one of these things where we said you really need DTM, write it or use tyrex. Turns out Tyrex was a fake with critical methods throwing NotImplementException. But clearly we didn't BASE the design on distribution. I don't know which version of Tyrex you are referring to here, when I worked with it, all distributed 2pc was implemented. (I was using 0.9.8) And distributed transactions worked properly. The reason Tyrex no longer works with JBoss 3.x is because currently, the invoker code is not calling the TM to provide it with the TPC, just tries to serialize the transaction object itself. In order to get Tyrex to work again, I would have to wrap each Tyrex Transaction object with a special (Externalizable) wrapper that would serialize itself by extracting a TPC and sending only that down the wire. On the remote end the wrapper would be unmarshalled and during unmarshalling it would try to register the local TM as subordinate with the originating TM. This is doable but imposes a wrapper for each tx instance. I remember discussion about this and how Ole was not happy about it. Where are you Ole? It seems to me, the real issue with the inability to efficiently integrate an arbitrary JTS-compliant DTM with JBoss (like Tyrex), is lack of well-defined TM-independent transaction propagation semantics withing invoker layer. Another thing that would help tremendously is call-back to the originating server in the invokers. Not only it would simplify integration, it would enable some neat optimizations. Here is what I mean. For initial integration of Tyrex I had to start an RMI server for TM (well, actually for each distributed TX, don't ask why, I did not understand much when I wrote it, but it worked :) ), which would get called by the recipient of the invocation to register as subordinate XAResource passing to the originator it's own RMI stub through which the originator would call prepare(), commit() or rollback(). This resulted in an additional network trip for registration and each of the subsequent communication between the participating TMs. Nothing prevents a very simple optimization of doing at least the registration on the return trip from the invocation. Ideally, the invocation pipe through which the invocation arrived to the second server should supply a Callback interface to the originating (MBean?) server and implementations of this callback interface could optimize callback invocations, like bursting, etc. I guess this is somewhat similar to how XmlBlaster does asynch communication -- messages that flow in opposite directions can use completely different transports (e.g. an original subscription request came through a socket but requested updates to be returned through XML-RPC due to firewall restrictions). I've seen some of the need for this in the forums on Invokers. Am I making sense? Anatoly. --- 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
RE: [JBoss-dev] Transaction propagation change
Dustin, Please don't take offense here, but you seem to be heading in a couple of directions where, based on my experience, I think you'll hit some problems. Apologies in advance if I've misunderstood. I never take offense to constructive criticisms/comments, I learn from them, so no apologies needed here. My original example didn't quite clearly convey the scenario I was attempting to explain. I was not wanting transaction propogation via the JMS message. I think you're arguing against colocating here, unless I'm missunderstanding dramatically. Sorry, I was using the word co-locating in the opposite sense, ie separate jboss instances. two points: 1. separating things out this way is very likely to hurt your performance. If you want performance, you should have the whole stack in the same process. If you want scalability, load-balance the whole application vertically, not horizontally. Yeah that's not what leaps to mind when they (we, speaking as one of they) say 'N-Tier', but it's what works. I understand and agree with you. However, there are times when one must integrate horizontally with other systems that may not live on the same iron and run under the same VM. Jboss cannot natively do DTM (JTS), even w/o JMS in the picture. 2. (async base MDB dispatchers) You're not proposing doing a request/reply to an MDB, are you? That's taking an asynch. transport (NOTHING TO DO WITH TRANSACTIONS HERE!) and simulating a synchronous call over it. That tends to perform badly, you'll have some complex code to manage it, and I've found it to generally be a bad idea. No, that's not what I am suggesting by the term async based MDB dispatchers. I mean dispatch in the sense that you have n number MDBs reading from a JMS queue and dispatching to n number of worker SSB's. The MDB basically plays traffic cop and invokes the appropriate SSB based upon parsing the JMS message headers. The more typical need for distributed TX involves one application (A) that needs to make a request to another application (B), where A needs to know the result of the request (making synchronous the prefered invocation style) and a roll-back in either A or B needs to roll-back the both thing. Agreed and again, JBoss, in it's current 3.x state, cannot natively do this across JBoss instances. The only time it makes sense to use JMS/MOM is when the requestor (A in my meta-example) doesn't really care what happens, AND where a rollback in B won't matter to A. Note that if A rolls back, the message will never be delivered. This is basically a case of A wanting to say Oh, if anybody cares, this happened. Extreme decoupling. The error handling on B's side tends to get a little hairy in these cases: it may need to intelligently recover from some errors, others can be retried at a later point, and for some errors it will wind up deffering to certain wet, grey, bio-electrical analog computers for resolution. Agreed. (and very funny) :) The transaction is between the queue and the MDB - the ack for the message should be sent to the queue iff the MDB's transaction commits. The transaction started for the MDB's processing of the message is the only transaction in this scenario. What's the question, other than 'this doesn't work in 3.x.' It should. If you have a remote MDB on one JBoss node that wants to listen for messages off a second jboss node that houses the JMS queues, how is the transaction handled there if jboss doesn't propogate transaction context between the instance housing the MDB and the instance housing the queues? JBoss does provide a DestinationManager which can be configured with a RemoteURL property, even though I have been unable to get it to work with a MDB (that's the it doesn't work and it should part). Dustin --- 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
RE: [JBoss-dev] Transaction propagation change
the only reason is that no one has previously written a distributed tx manager. I wrote the basic stuff we need in jboss 4, it should even work with the trunk invoker. david jencks Can this be back ported to the 3.x series? I'm mostly interested in the 3.2, but i presume it would also fit in 3.0 as well. Dustin --- 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
RE: [JBoss-dev] Transaction propagation change
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/jboss-user@lists.sourceforge.net/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? Scott Stark Chief Technology Officer JBoss Group, LLC --- 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
RE: [JBoss-dev] Transaction propagation change
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
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
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 DONT 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
Re: [JBoss-dev] Transaction propagation change
I think you're talking about giving people something more like asynchronous method invocations (one-way) than traditional MOM style messages, right? My MOM exists to keep me and my brothers from fighting: she takes notes one to the other, maybe 'forgets' the particularly nasty ones, makes sure there's a cooling off period, etc. The purpose of MOM is to decouple - propagating transactions with the message is a bad idea because you're using a hammer to turn a screw. An asynch. invocation on the other hand, ought to take the transaction with it, but I think you want a different programming model than the JMS overhead crap (look up three object in JNDI, call three factories, sacrifies three virgin goats...) I wouldn't care if it were implemented on the same infrastructure as JBossMQ, but I'd really want a more light-weight programming model - like an asynchronous Aspect for the target object, or something... -danch marc fleury wrote: 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 DONT 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
RE: [JBoss-dev] Transaction propagation change
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. 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? Scott Stark Chief Technology Officer JBoss Group, LLC --- 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
