Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources
I have finally downloaded and tested this patch with SwiftMQ, and it does indeed fix the problem. Does anyone object if I go forward with this patch? (Note - I simplified it a bit, and added some (too much?) commenting). -Larry I think I may have tracked down the SwiftMQ bug... let me know if this sounds right. SwiftMQ doesn't support start(join), so they return false for all calls to isSameRM(). This should cause all connections being enlisted to be given a unique xid (with different branch qualifiers). I think this is compliant with the JTA and XA specs. In enlistResource (TransactionImpl:535), a check is made to see if this RM is already enlisted (call to findResource). But, this check uses an equality test. If you are enlisting a connection that was previously closed in the same transcation scope, then this will find the old resource, and attempt to re-enlist with a TMJOIN, which on SwiftMQ yields an XAException (PROTO?). Basically, we can't assume that (resource1 == resource2) implies (resource1.isSameRM(resource2)). The problem now is that the TM must be able to enlist the same resource multiple times with different branch-ids, and then figure out which xid to use on the next call to delist. I have attached a patch (one for JBoss 3.1 one for JBoss 3.0) that I think fixes the problem. Please let me know what you think. -Larry 3.0.diff Description: Binary data
RE: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources
Please do. IMO you can't have too much commenting... but some of the aliens might disagree. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of lsanders Sent: Wednesday, August 21, 2002 3:36 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources I have finally downloaded and tested this patch with SwiftMQ, and it does indeed fix the problem. Does anyone object if I go forward with this patch? (Note - I simplified it a bit, and added some (too much?) commenting). -Larry I think I may have tracked down the SwiftMQ bug... let me know if this sounds right. SwiftMQ doesn't support start(join), so they return false for all calls to isSameRM(). This should cause all connections being enlisted to be given a unique xid (with different branch qualifiers). I think this is compliant with the JTA and XA specs. In enlistResource (TransactionImpl:535), a check is made to see if this RM is already enlisted (call to findResource). But, this check uses an equality test. If you are enlisting a connection that was previously closed in the same transcation scope, then this will find the old resource, and attempt to re-enlist with a TMJOIN, which on SwiftMQ yields an XAException (PROTO?). Basically, we can't assume that (resource1 == resource2) implies (resource1.isSameRM(resource2)). The problem now is that the TM must be able to enlist the same resource multiple times with different branch-ids, and then figure out which xid to use on the next call to delist. I have attached a patch (one for JBoss 3.1 one for JBoss 3.0) that I think fixes the problem. Please let me know what you think. -Larry --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources
David Jencks wrote: Thanks!! I want to get this in our testsuite as soon as possible. I'm not sure how best to do this. Right now the only xa thingy we ship with is the jmxra adapter. Just to make sure that we are talking about same testing approach: XATest has a test case for all interesting interection between transaction manager and resource manager, in particular for all sequences of xa calls that caused us trouble (as bugs 585632 and 590816). We also have configurations of the test for all resource managers we would like to support (oracle, swift, sap, mssql, and so on). Each time we change anything in transaction manager we run tests with resource managers to see if they are compatible. Once we find an incompatibility with specific rm we either change transaction manager to avoid the problem or write adaptor/wrapper for problematic rm. We need to find volunteers for all resource managers we want to test with. We also need to find a way to initiate tests and to gather results. I think I can do oracle 817 with various jdbc drivers/configurations... I lean toward modifying the test so it only tests jca adapters, since that is the only thing we can deploy in jboss. Then we can work on writing driver-specific jca wrappers to work around the particular spec violations in each driver. Do you have jca adapter for jdbc xa data sources and jms xa connection factories? If this is the case, then sure it is the way to go (and shame on me that I did not do that). At the same time I find that oracle-specific jca adaptor would be overkill and all oracle-specific problems can be solved with a wrapper for oracle jdbc driver. As far as I understood, wrapper for informix jdbc driver solves all informix specific problems. Is it important to do work on the connection before trying to commit? If it is unnecessary it will be easier to make the test more generic. If it is necessary I think it will be easiest to test the adapter inside jboss by deploying it using the normal .rar deployment mechanism. If we did not do any work on a connection, resource manager is supposed to return XA_RDONLY from XAResource.prepare and transaction manager does not have to commit the connection. The point is that both resource manager and transaction manager behave differently, and I think it is important to test both XA_OK and XA_RDONLY. Btw, how does deployment of .rar help to test work on a connection? To be honest, I do not have any experience with XA or JCA, but I've read some docs :-) Any thoughts? Thanks david jencks On 2002.08.11 17:54:21 -0400 Igor Fedorenko wrote: Ok, attached is jboss xa compatibility test, version 0.0 pre-alpha :-) Main test is org.jboss.tm.XATest. It is supposed to be resource-manager independent and uses two interfaces org.jboss.tm.test.ResourceManager and org.jboss.tm.test.XAConnection to access/test real resource managers. There is an implementation of these interfaces for JDBC and JMS. I have defined few basic tests as well as tests for bugs #590816 and #585632. Of course more tests are needed. Test is configured by property file which specifies what implementation of org.jboss.tm.test.ResourceManager to be used and configuration of the implementation itself. You can find example configuration for oracle, jbossmq and weblogic-jms. Hope this would be helpful. As usual, questions, comments and suggestions are welcome. -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com Scott M Stark wrote: Do it. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Igor Fedorenko [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 08, 2002 9:06 AM Subject: Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XA Resources By the way, why do not we setup XA compatibility tests we can run against different resource managers? I see two types of tests -- tests that use XAResource directly and tests that check TransactionImpl. If this sounds reasonable I can try to write something we can start with. -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources
Why do we have to work around driver bugs at the transaction manager level? Why not write the TM the way we want and start introducing driver specific JCA wrappers to deal with these issues? Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Ole Husgaard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 08, 2002 10:53 AM Subject: Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources Larry Sandereson wrote: +1 for changing JBoss TM to allow end(success) on suspended tx without first calling start(resume). Seing that this would give problems with the drivers of two major databases made me change my vote on this from +1 to +0. Really, should we drop support for Oracle and Sybase? Still, doing the change would IMHO be the right thing to do from a purely technical viewpoint (they should fix their bugs!). I would still like to pursue closing resources with TMSUCCESS, though. If nothing else, it removes the need to call 'end' twice. More importantly, it seems to me like that is the intent of the JTA spec. I will find some time this weekend to investigate SwiftMQ and JBoss TM. That would be fine. If this can be done, doing the other change would not be as urgent, and we could wait until the database vendors have fixed their bugs. Best Regards, Ole Husgaard. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources
I think I may have tracked down the SwiftMQ bug... let me know if this sounds right. SwiftMQ doesn't support start(suspend), so they return false for all calls to isSameRM(). This should cause all connections being enlisted to be given a unique xid (with different branch qualifiers). I think this is compliant with the JTA and XA specs. In enlistResource (TransactionImpl:535), a check is made to see if this RM is already enlisted (call to findResource). But, this check uses an equality test. If you are enlisting a connection that was previously closed in the same transcation scope, then this will find the old resource, and attempt to re-enlist with a TMJOIN, which on SwiftMQ yields an XAException (PROTO?). Basically, we can't assume that (resource1 == resource2) implies (resource1.isSameRM(resource2)). The problem now is that the TM must be able to enlist the same resource multiple times with different branch-ids, and then figure out which xid to use on the next call to delist. I have attached a patch (one for JBoss 3.1 one for JBoss 3.0) that I think fixes the problem. Please let me know what you think. -Larry 3.0.diff Description: Binary data 3.1.diff Description: Binary data
Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources
I think I may have tracked down the SwiftMQ bug... let me know if this sounds right. SwiftMQ doesn't support start(suspend), so they return false for all calls to isSameRM(). This should cause all connections being enlisted to be given a unique xid (with different branch qualifiers). I think this is compliant with the JTA and XA specs. In enlistResource (TransactionImpl:535), a check is made to see if this RM is already enlisted (call to findResource). But, this check uses an equality test. If you are enlisting a connection that was previously closed in the same transcation scope, then this will find the old resource, and attempt to re-enlist with a TMJOIN, which on SwiftMQ yields an XAException (PROTO?). Basically, we can't assume that (resource1 == resource2) implies (resource1.isSameRM(resource2)). The problem now is that the TM must be able to enlist the same resource multiple times with different branch-ids, and then figure out which xid to use on the next call to delist. I have attached a patch (one for JBoss 3.1 one for JBoss 3.0) that I think fixes the problem. Please let me know what you think. -Larry 3.0.diff Description: Binary data 3.1.diff Description: Binary data
Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources
Hi, Scott M Stark wrote: Why do we have to work around driver bugs at the transaction manager level? Why not write the TM the way we want and start introducing driver specific JCA wrappers to deal with these issues? Makes sense to me. Then, we wouldn't have to add extra code in the TM code to work around the multitude of different bugs in the different drivers. The downside is that quite a few different JCA wrappers would be needed for this. For example, just about every version of the Oracle XA drivers have different bugs. I'm not that familiar with JCA (still have to read up on that), but I wonder if it is possible to make stackable JCA wrappers that each fix one bug. If that is the case we could write: a) a JCA wrapper that fixes the res.end(suspend) followed by res.end(success) fails-bug, b) a JCA wrapper that fixes bug #585632. c) a JCA wrapper that fixes the problem some Oracle drivers have because they only accept their own Xid implementation. This wrapper would eliminate the need for the Xid factory in the TM code. Then the Oracle 8.1.7 driver could be wrapped in (a) and (b) above. Oracle 8.1.6 drivers would probably need wrappers (a) and (c). And the Sybase jConnect 5.2.1 would need wrapper (a) only. What do the JCA experts here think about this? Best Regards, Ole Husgaard. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources
Have these patchs been used and verfified with JBossMQ and SwiftMQ? --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Larry Sandereson Sent: Thursday, August 08, 2002 2:03 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources I think I may have tracked down the SwiftMQ bug... let me know if this sounds right. SwiftMQ doesn't support start(suspend), so they return false for all calls to isSameRM(). This should cause all connections being enlisted to be given a unique xid (with different branch qualifiers). I think this is compliant with the JTA and XA specs. In enlistResource (TransactionImpl:535), a check is made to see if this RM is already enlisted (call to findResource). But, this check uses an equality test. If you are enlisting a connection that was previously closed in the same transcation scope, then this will find the old resource, and attempt to re-enlist with a TMJOIN, which on SwiftMQ yields an XAException (PROTO?). Basically, we can't assume that (resource1 == resource2) implies (resource1.isSameRM(resource2)). The problem now is that the TM must be able to enlist the same resource multiple times with different branch-ids, and then figure out which xid to use on the next call to delist. I have attached a patch (one for JBoss 3.1 one for JBoss 3.0) that I think fixes the problem. Please let me know what you think. -Larry --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources
Only JBossMQ and Informix XA. Not SwiftMQ yet. Do you have a setup where you can test this? -Larry - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 08, 2002 2:07 PM Subject: RE: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources Have these patchs been used and verfified with JBossMQ and SwiftMQ? --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Larry Sandereson Sent: Thursday, August 08, 2002 2:03 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources I think I may have tracked down the SwiftMQ bug... let me know if this sounds right. SwiftMQ doesn't support start(suspend), so they return false for all calls to isSameRM(). This should cause all connections being enlisted to be given a unique xid (with different branch qualifiers). I think this is compliant with the JTA and XA specs. In enlistResource (TransactionImpl:535), a check is made to see if this RM is already enlisted (call to findResource). But, this check uses an equality test. If you are enlisting a connection that was previously closed in the same transcation scope, then this will find the old resource, and attempt to re-enlist with a TMJOIN, which on SwiftMQ yields an XAException (PROTO?). Basically, we can't assume that (resource1 == resource2) implies (resource1.isSameRM(resource2)). The problem now is that the TM must be able to enlist the same resource multiple times with different branch-ids, and then figure out which xid to use on the next call to delist. I have attached a patch (one for JBoss 3.1 one for JBoss 3.0) that I think fixes the problem. Please let me know what you think. -Larry --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources
Could some of these problems be solved by using a custom driver layer which would resolve these issues at the JDBC layer? Dain was talking about doing something like this at the last SF training. Then we would have one driver, which would delegate to the db specific driver and resolve the issues before it even gets to an adapter. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Ole Husgaard Sent: Thursday, August 08, 2002 2:10 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources Hi, Scott M Stark wrote: Why do we have to work around driver bugs at the transaction manager level? Why not write the TM the way we want and start introducing driver specific JCA wrappers to deal with these issues? Makes sense to me. Then, we wouldn't have to add extra code in the TM code to work around the multitude of different bugs in the different drivers. The downside is that quite a few different JCA wrappers would be needed for this. For example, just about every version of the Oracle XA drivers have different bugs. I'm not that familiar with JCA (still have to read up on that), but I wonder if it is possible to make stackable JCA wrappers that each fix one bug. If that is the case we could write: a) a JCA wrapper that fixes the res.end(suspend) followed by res.end(success) fails-bug, b) a JCA wrapper that fixes bug #585632. c) a JCA wrapper that fixes the problem some Oracle drivers have because they only accept their own Xid implementation. This wrapper would eliminate the need for the Xid factory in the TM code. Then the Oracle 8.1.7 driver could be wrapped in (a) and (b) above. Oracle 8.1.6 drivers would probably need wrappers (a) and (c). And the Sybase jConnect 5.2.1 would need wrapper (a) only. What do the JCA experts here think about this? Best Regards, Ole Husgaard. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources
Yeah, but not at the moment, I am way busy right now. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Larry Sanderson Sent: Thursday, August 08, 2002 2:19 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources Only JBossMQ and Informix XA. Not SwiftMQ yet. Do you have a setup where you can test this? -Larry - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 08, 2002 2:07 PM Subject: RE: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources Have these patchs been used and verfified with JBossMQ and SwiftMQ? --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Larry Sandereson Sent: Thursday, August 08, 2002 2:03 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources I think I may have tracked down the SwiftMQ bug... let me know if this sounds right. SwiftMQ doesn't support start(suspend), so they return false for all calls to isSameRM(). This should cause all connections being enlisted to be given a unique xid (with different branch qualifiers). I think this is compliant with the JTA and XA specs. In enlistResource (TransactionImpl:535), a check is made to see if this RM is already enlisted (call to findResource). But, this check uses an equality test. If you are enlisting a connection that was previously closed in the same transcation scope, then this will find the old resource, and attempt to re-enlist with a TMJOIN, which on SwiftMQ yields an XAException (PROTO?). Basically, we can't assume that (resource1 == resource2) implies (resource1.isSameRM(resource2)). The problem now is that the TM must be able to enlist the same resource multiple times with different branch-ids, and then figure out which xid to use on the next call to delist. I have attached a patch (one for JBoss 3.1 one for JBoss 3.0) that I think fixes the problem. Please let me know what you think. -Larry --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources
We already have one of these for InformixXA that I can donate. -Larry Could some of these problems be solved by using a custom driver layer which would resolve these issues at the JDBC layer? Dain was talking about doing something like this at the last SF training. Then we would have one driver, which would delegate to the db specific driver and resolve the issues before it even gets to an adapter. --jason Scott M Stark wrote: Why do we have to work around driver bugs at the transaction manager level? Why not write the TM the way we want and start introducing driver specific JCA wrappers to deal with these issues? Makes sense to me. Then, we wouldn't have to add extra code in the TM code to work around the multitude of different bugs in the different drivers. The downside is that quite a few different JCA wrappers would be needed for this. For example, just about every version of the Oracle XA drivers have different bugs. I'm not that familiar with JCA (still have to read up on that), but I wonder if it is possible to make stackable JCA wrappers that each fix one bug. If that is the case we could write: a) a JCA wrapper that fixes the res.end(suspend) followed by res.end(success) fails-bug, b) a JCA wrapper that fixes bug #585632. c) a JCA wrapper that fixes the problem some Oracle drivers have because they only accept their own Xid implementation. This wrapper would eliminate the need for the Xid factory in the TM code. Then the Oracle 8.1.7 driver could be wrapped in (a) and (b) above. Oracle 8.1.6 drivers would probably need wrappers (a) and (c). And the Sybase jConnect 5.2.1 would need wrapper (a) only. What do the JCA experts here think about this? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources
Jason Dillon wrote: Could some of these problems be solved by using a custom driver layer which would resolve these issues at the JDBC layer? Dain was talking about doing something like this at the last SF training. Then we would have one driver, which would delegate to the db specific driver and resolve the issues before it even gets to an adapter. This is what I did to solve #585632. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Ole Husgaard Sent: Thursday, August 08, 2002 2:10 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources Hi, Scott M Stark wrote: Why do we have to work around driver bugs at the transaction manager level? Why not write the TM the way we want and start introducing driver specific JCA wrappers to deal with these issues? Makes sense to me. Then, we wouldn't have to add extra code in the TM code to work around the multitude of different bugs in the different drivers. The downside is that quite a few different JCA wrappers would be needed for this. For example, just about every version of the Oracle XA drivers have different bugs. I'm not that familiar with JCA (still have to read up on that), but I wonder if it is possible to make stackable JCA wrappers that each fix one bug. If that is the case we could write: a) a JCA wrapper that fixes the res.end(suspend) followed by res.end(success) fails-bug, b) a JCA wrapper that fixes bug #585632. c) a JCA wrapper that fixes the problem some Oracle drivers have because they only accept their own Xid implementation. This wrapper would eliminate the need for the Xid factory in the TM code. Then the Oracle 8.1.7 driver could be wrapped in (a) and (b) above. Oracle 8.1.6 drivers would probably need wrappers (a) and (c). And the Sybase jConnect 5.2.1 would need wrapper (a) only. What do the JCA experts here think about this? Best Regards, Ole Husgaard. -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources
Hrm... I guess this won't work for JMS though... fuck. Then a wrapper for JMS connections too? Bah, write once run everywhere my ass. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Igor Fedorenko Sent: Thursday, August 08, 2002 2:45 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources Jason Dillon wrote: Could some of these problems be solved by using a custom driver layer which would resolve these issues at the JDBC layer? Dain was talking about doing something like this at the last SF training. Then we would have one driver, which would delegate to the db specific driver and resolve the issues before it even gets to an adapter. This is what I did to solve #585632. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Ole Husgaard Sent: Thursday, August 08, 2002 2:10 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources Hi, Scott M Stark wrote: Why do we have to work around driver bugs at the transaction manager level? Why not write the TM the way we want and start introducing driver specific JCA wrappers to deal with these issues? Makes sense to me. Then, we wouldn't have to add extra code in the TM code to work around the multitude of different bugs in the different drivers. The downside is that quite a few different JCA wrappers would be needed for this. For example, just about every version of the Oracle XA drivers have different bugs. I'm not that familiar with JCA (still have to read up on that), but I wonder if it is possible to make stackable JCA wrappers that each fix one bug. If that is the case we could write: a) a JCA wrapper that fixes the res.end(suspend) followed by res.end(success) fails-bug, b) a JCA wrapper that fixes bug #585632. c) a JCA wrapper that fixes the problem some Oracle drivers have because they only accept their own Xid implementation. This wrapper would eliminate the need for the Xid factory in the TM code. Then the Oracle 8.1.7 driver could be wrapped in (a) and (b) above. Oracle 8.1.6 drivers would probably need wrappers (a) and (c). And the Sybase jConnect 5.2.1 would need wrapper (a) only. What do the JCA experts here think about this? Best Regards, Ole Husgaard. -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources
Larry Sandereson wrote: I think I may have tracked down the SwiftMQ bug... let me know if this sounds right. This is great. And it sounds right to me. SwiftMQ doesn't support start(suspend), so they return false for all calls to isSameRM(). This should cause all connections being enlisted to be given a unique xid (with different branch qualifiers). I think this is compliant with the JTA and XA specs. start(suspend) doesn't make sense to me. Do you mean end(suspend), start(resume) or start(join)? So SwiftMQ doesn't support something it ought to for JTA compliance... And to get around that, it does something truly wierd. This may in some cases be heavy performance-wise, since there may be a lot of ==-equal resources enlisted with the TM. I have heard that some application servers in some cases delist before every call to another bean, and enlist again afterwards (that way the other bean can use the same connection, even if in another tx). Have you checked if this is listed as a bug in SwiftMQ? In enlistResource (TransactionImpl:535), a check is made to see if this RM is already enlisted (call to findResource). But, this check uses an equality test. If you are enlisting a connection that was previously closed in the same transcation scope, then this will find the old resource, and attempt to re-enlist with a TMJOIN, which on SwiftMQ yields an XAException (PROTO?). Ahh, so it is start(join) that SwiftMQ does not support. Basically, we can't assume that (resource1 == resource2) implies (resource1.isSameRM(resource2)). Ouch. I have been assuming this, but when rereading the JTA specification, I see nowhere that we can assume this. JTA really ought to explicitly state if such an assumption can be made, or it will be a source of implementation errors. The problem now is that the TM must be able to enlist the same resource multiple times with different branch-ids, and then figure out which xid to use on the next call to delist. Agreed. I have attached a patch (one for JBoss 3.1 one for JBoss 3.0) that I think fixes the problem. Please let me know what you think. I just had a quick look at the 3.1 patch, and it looks fine to me. I have a question though: Why also check for RS_ENDED state? And a comment: In delist, probably an exception should not be thrown. False should be returned instead, and IMHO the exception at line 451 should also be changed to returning false. But still I wonder: What happens if several SwiftMQ ==-equal resources are enlisted in the same transaction. How do we ensure that it is the right resource that we call end() on? After all, we do not get the Xid supplied to the delist call, so we really have no way of knowing which Xid to end when the resources are ==-equal. Best Regards, Ole Husgaard. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources
SwiftMQ doesn't support start(suspend), so they return false for all calls to isSameRM(). This should cause all connections being enlisted to be given a unique xid (with different branch qualifiers). I think this is compliant with the JTA and XA specs. start(suspend) doesn't make sense to me. Do you mean end(suspend), start(resume) or start(join)? As you guessed, I meant start(join). So SwiftMQ doesn't support something it ought to for JTA compliance... And to get around that, it does something truly wierd. This may in some cases be heavy performance-wise, since there may be a lot of ==-equal resources enlisted with the TM. I have heard that some application servers in some cases delist before every call to another bean, and enlist again afterwards (that way the other bean can use the same connection, even if in another tx). Have you checked if this is listed as a bug in SwiftMQ? Andreas Meuller sent me this link: http://www.jguru.com/forums/view.jsp?EID=914840 Around the middle it explains that SwiftMQ returns false for all calls to isSameRM. I agree that it may well be a heavy performance hit, but I still believe it is compliant. Basically, we can't assume that (resource1 == resource2) implies (resource1.isSameRM(resource2)). Ouch. I have been assuming this, but when rereading the JTA specification, I see nowhere that we can assume this. JTA really ought to explicitly state if such an assumption can be made, or it will be a source of implementation errors. I agree. The problem now is that the TM must be able to enlist the same resource multiple times with different branch-ids, and then figure out which xid to use on the next call to delist. Agreed. I have attached a patch (one for JBoss 3.1 one for JBoss 3.0) that I think fixes the problem. Please let me know what you think. I just had a quick look at the 3.1 patch, and it looks fine to me. I have a question though: Why also check for RS_ENDED state? And a comment: In delist, probably an exception should not be thrown. False should be returned instead, and IMHO the exception at line 451 should also be changed to returning false. This is going to take a little explaining. I make the assumption that each XAConnection has an individual XAResource. If they are using some singleton concept for XAResources, then this technique will fail. (In fact, there would be no possible way to solve this problem if that was their approach.). Assume we are working with an RM that returns false always for isSameRM, and that it has not yet been enlisted in the current tx. The first enlistResource(rm) is trivial. After, one of two things can happen: delist(rm, success/fail) // rm status is RS_ENDED delist(rm, suspend) // rm status is RS_SUSPENDED (Note: it can't be enlisted yet, since the connection is not available to the free pool). In both cases, the connection is returned to the pool. Now someone can get that resource again, and enlists it in the same transaction. If it was ended with success/fail, then the original tx is ended, and a new one needs to be started. If it was suspended, then we need to resume. So we could be left with one of the follow: resourceState table (if first delist was success/fail): rm - ended rm - enlisted resourceState table (if first delist was suspend) rm - enlisted Continuing, the resourceState table would always look like: rm - ended rm - ended ... rm - ended rm - enlisted / suspended i.e. any number of ended states, possibly followed by a single state that is either enlisted or suspended. So, finally answering your question, the checks for RS_ENDED allow the search to skip over all the ended states, and get to the last one, if it exists. But still I wonder: What happens if several SwiftMQ ==-equal resources are enlisted in the same transaction. How do we ensure that it is the right resource that we call end() on? After all, we do not get the Xid supplied to the delist call, so we really have no way of knowing which Xid to end when the resources are ==-equal. Hopefully my explanation above explained it. If not, let me know and I will try again. -Larry --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development