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
