David, All the tests (except the join test ) pass with both Oracle and Derby Embedded driver.
Regards ----- Original Message ----- From: "David Jencks" <[EMAIL PROTECTED]> To: "Derby Development" <[email protected]> Sent: Thursday, May 26, 2005 6:09 AM Subject: Re: Planning for a 10.1 release > I took a quick look at Dibyendu's tests and I think they are OK. I > would like to know if these tests pass with the embedded xa support. > Tests 8 and 9 are IMO completely spec compliant but I believe they will > not pass with the majority of databases claiming xa support. As such > it might not be wise to insist on them :-) > > One comment I have is that the app servers I have worked with (geronimo > and jboss) will use this sequence of calls: > > xar.start(xid, TM_NOFLAGS); > xar.end(xid, TM_SUSPEND); > xar.end(xid, TM_SUCCESS); > xar.prepare/commit > > You might want to add strategically located suspend calls to make sure > that makes no difference. > > As far as connection handles and pooling, the usage in the tests is > absolutely standard and I'm sure it is what websphere uses also. > > Typically with an ejb CMT call, we have the following sequence of > events: > > 1. container starts tx > 2. ejb obtains a connection handle. This involves enlisting the > XAResource associated with the managed connection/XAConnection with the > current tx. and obtaining a handle from the mc. We can't tell which > order this occurs in, but it doesn't seem to make a difference in this > test. > 3. ejb uses cx handle > 4. ejb closes cx handle. There is no way for the connection manager to > detect this is going to happen... > 5 mc/XAConnection notifies listeners that the handle was closed. At > this time the connection manager could delist/end the XAResource from > the transaction. > > Note the order of steps 4 and 5, which is the same as in Dibyendu's > tests. > > According to my interpretation of the xa spec, it should now be safe > (no open cx handles and no tx associated with mc) to put the mc back in > the pool. However, I believe most "xa" drivers don't let you do this > but require you to commit the tx first before starting another. > > In conclusion, I would recommend experimenting with the end(TM_SUSPEND) > call, but I think at least tests 1-7 should pass before releasing the > driver. > > Many thanks, > david jencks > > ps. I would be sure you never use the same xid twice. I think it would > be entirely appropriate for derby to object if you do. I didn't see > the implementation in the Utils class so I'm not sure if your xids are > unique or not. > > > On May 25, 2005, at 7:34 PM, Jeremy Boynes wrote: > > > David's the Geronimo guru on XA. > > > > My understanding is that it is legal for a coordinator to delist a > > resource before the end of a transaction and return it to the pool; it > > could then be used by another thread (potentially in another > > transaction) or just closed. > > > > However, there are many resource managers out there that do not > > support this so most app servers (OK, at least Geronimo and from what > > you say WebSphere) have a mechanism for associating the physical > > connection with the transaction until it is over. > > > > I haven't looked at the bug but we should clearly document how Derby > > behaves, especially if client and embedded behaviour are different. > > > > -- > > Jeremy > > > > Kathey Marsden wrote: > >> Dibyendu Majumdar wrote: > >>> From: "Kathey Marsden" <[EMAIL PROTECTED]> > >>> > >>> > >>>> I think the workaround for DERBY-246, to leave the logical > >>>> connection > >>>> open until the end of the global transaction, should be documented > >>>> in > >>>> the release notes. > >>>> > >>> > >>> Hi Kathey, > >>> > >>> Unfortunately, this is not a workaround. For example, see section > >>> 4.2 of JTA > >>> spec which describes how an application server would use logical > >>> connections. > >>> > >>> > >> Firstly I want to say that I am motivated to get this fixed. I just > >> don't think I can get it fixed in the time frame for the 10.1 > >> release. I don't think it should stop the release. The example says: > >> "The figure that follows illustrates the usage of > >> JTA. The steps shown are for illustrative purposes, they are not > >> prescriptive:" > >> In this example, with our workaround, I think steps 11 and 12 would > >> move > >> down to the end. > >> I talked with the folks that use XA at Websphere. They said. > >> "in WAS, we don't close the connections until after they are no longer > >> in transactions (closing, means put them in the pool to be used by > >> others)" > >> So it seems like it is a workaround. Could you offer a scenario > >> where > >> it is not a reasonable workaround > >> Perhaps Jeremy has some perspective as well as to the XA impact. > >> Jeremy? > >> Thanks > >> Kathey > > >
