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
