db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dibyendu Majumdar" <dibye...@mazumdar.demon.co.uk>
Subject Re: Planning for a 10.1 release
Date Thu, 26 May 2005 09:29:21 GMT
From: "Kathey Marsden" <kmarsdenderby@sbcglobal.net>
> 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.


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

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
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.



View raw message