Roman,

--- In Firebird-Java@yahoogroups.com, "Roman Rokytskyy"
<rrokytskyy@...> wrote:

> Since there is no method to return connection to the pool, this

means such

> code is implementation specific. In our case it is returned to the

pool when

> logical connection is closed. Now, when you try to obtain logical

connection

> for the second time, the physical connection is in pool. We do not

detect

> this situation and after that all goes wrong...
>
> As to the XAConnection... it is subclass of the PooledConnection,

therefore

> it should have same semantics as PooledConnection.
>
> So, we have quite controversial results... and the worst is that I

have not

> seen neither confirmation of your usage scenario nor that mine usage
> scenario is the only possible.
>
> What do we want to do now?

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.

The good news is that 99% of the time users simply get a connection
from the XA connection then close it and it looks good enough for all
cases I can think of.

Quite frankly, I'm as clueless as you are regarding what the proper
implementation should be.

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.

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.

For me it looks clear that the 2nd option looks best but it's also the
most complex to code.

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.

Ludovic