Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources

2002-08-21 Thread lsanders

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

2002-08-21 Thread Jason Dillon

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

2002-08-12 Thread Igor Fedorenko

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

2002-08-08 Thread Scott M Stark

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

2002-08-08 Thread Larry Sandereson

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

2002-08-08 Thread Larry Sandereson

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

2002-08-08 Thread Ole Husgaard

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

2002-08-08 Thread Jason Dillon

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

2002-08-08 Thread Larry Sanderson

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

2002-08-08 Thread Jason Dillon

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

2002-08-08 Thread Jason Dillon

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

2002-08-08 Thread Larry Sanderson

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

2002-08-08 Thread Igor Fedorenko

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

2002-08-08 Thread Jason Dillon

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

2002-08-08 Thread Ole Husgaard

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

2002-08-08 Thread Larry Sanderson

  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