Subject Re: [Firebird-Java] Re: Two XA bugs
Author Roman Rokytskyy
> Let's speak XAConnection since it's the root problem of this story.

> The bad news is that it's perfectly legal to get more than one
> connection out of an XA connection.

Can you provide reference for this?

I agree that this should be legal, however, currently, I do not see how to
satisfy the "when logical connection is closed, physical one is returned
back to the pool" at the same time allowing to get another connection
without first obtaining the physical connection back from pool first. And,
as I understandm the only way to obtain connection from the pool is to use
XADataSource.getXAConnection() method....

> The two implementations I've seen regarding this problem are:
>
> 1) the second call to XAConnection.getConnection() automatically
> closes the first logical Connection before retuning you a new logical
> Connection object using the same physical connection.

That is not the problem - in the test case you close the first connection
before you get the second one.

Even more, there will be no problem to allow second getConnection() when the
first one is _not_ closed - I can return the same instance, which should be
perfectly ok - "local" transaction is anyway bounded to global one.

The problem is calling getConnection() _after_ closing the first one. In
this case physical connection is in the pool already, but the reference to
it is still alive. The clean solution would be to throw SQLException during
getConnection() when the physical connection is in pool, but that would not
fit the "bad news"-statement.

> 2) the second call to XAConnection.getConnection() returns you another
> logical connection using the same physical connection. Both logical
> connections can be used in parallel and closed separately.

That is also possible. With reference counting I can release physical
connection back to pool only when all logical connections are closed. But
again, that is not the problem that we are fighting with.

> At the very least the first option or some other compromise should be
> implemented so that calling multiple times
> XAConnection.getConnection().close() won't barf as badly as it does now.

Well, SQLException on the second getConnection() qualifies this. :)

Roman