|Subject||Re: [Firebird-Java] Re: Two XA bugs|
> Let's speak XAConnection since it's the root problem of this story.Can you provide reference for this?
> The bad news is that it's perfectly legal to get more than one
> connection out of an XA connection.
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
> The two implementations I've seen regarding this problem are:That is not the problem - in the test case you close the first connection
> 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.
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 anotherThat is also possible. With reference counting I can release physical
> logical connection using the same physical connection. Both logical
> connections can be used in parallel and closed separately.
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 beWell, SQLException on the second getConnection() qualifies this. :)
> implemented so that calling multiple times
> XAConnection.getConnection().close() won't barf as badly as it does now.