From: "Kathey Marsden" <[EMAIL PROTECTED]> > 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.
Kathey, I have no problem with releasing the client as it will be useful even without XA support. My only objection is to say that XA is working because it is not. As long as the release notes make that clear, fine. > > 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)" > There are several problems with this. We cannot assume that what WAS does is the correct thing to do. Obviously WAS knows about limitations/problems in DB2 drivers and works around them. But to expect everyone else to put in workarounds is unreasonable. Secondly, are the WAS folks saying that they do not close the logical connection ? The physical connection should not be closed, and should be reused, but the logical connection is typically closed. This is because, the logical connection may not be under control of the application server. For example, what if the application has opened a connection - it will close it once it no longer needs the connection. Of coures, this can be worked around by providing another layer of abstraction - ie - wrap the logical connection in a proxy that suppresses the close - but that seems to me to defeat the whole objective of having logical connections. > So it seems like it is a workaround. Could you offer a scenario where > it is not a reasonable workaround Certainly for me this is not a work around. The way I have implemented JTA is as follows: Application requests a connection SimpleJTA acquires a physical connection from the pool, creating one if necessary. It then creates the logical connection. The resource is enlisted with the global transaction. The logical connection is returned to the application. Application closes the logical connection. This results in a call to connectionClosed event. SimpleJTA traps this, and notes that the application is not using the connection. However, it does not delist the XA resource yet, because it assumes that the application may want the connection again. Therefore, it stores the connection in a cache keyed by Xid. Now, assume that the application wants another connection for the same global transaction. In this case, SimpleJTA will return the connection that is already enlisted. When the application calls commit() or rollback(), SimpleJTA finally delists all the resources by calling end() and then completes the transaction. Therefore, in SimpleJTA, a physical connection is reserved for use by a transaction until the transaction is completed. I did this as an optimisation, because in modern DAO implementations, a connection may be acquired and released several times in quick succession within the same global transaction. It seemed a waste to delist and enlist the resource everytime this happens. Theoretically, a physical connection can be resused by any other transaction after end() is called. SimpleJTA supports this as an option - but in my testing I found that Oracle does not like this, specially if different threads are involved. Oracle is okay with the same thread reusing a connection for another transaction after end(), but not if another thread attempts to do so. The point is that this is definitely a bug. I do not think that the workaround is reasonable. I am also concerned that there may be other bugs as yet undiscovered. Regards Dibyendu
