Roman,

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

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

Unfortunately, not. I'm just relying on the PooledConnection javadoc
(superinterface of XAConnection). The class description is quite a
novel explaining what an app server should do to implement connection
pooling.

Nothing in it states that calling getConnection() multiple times is
allowed or not so my assumption is that it's allowed.

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

I think this is where you got it wrong. It's nowhere stated that
XADataSource should do pooling and in fact,
XADataSource.getXAConnection() javadoc clearly specifies "Attempts to
establish a physical database connection that can be used in a
distributed transaction.". This is clear to me that a physical
connection should be created each time XADataSource.getXAConnection()
is called and that pooling is NOT the responsibility of XADataSource.
Look carefully at the javadocs of DataSource.getConnection and
XADataSource.getXAConnection. Notice the subtle difference ? In the XA
class, they used the word "physical" but not in the non-XA one.

Now if you look at DataSource javadoc, then they speak about pooling
connections that can participate in distributed transactions (item 3
Distributed transaction implementation).

I agree that Sun's naming is quite confusing but as far as I understand:

- XADataSource does not inherit from DataSource
- XADataSource does not speak about pooling
- XADataSource states that physical connections should be created
when getXAConnection is called
- DataSource speaks about XA pooling
- XAConnection states that it should not be used by application
programmer but only by the transaction manager.

I accept that as an vague list of clues tending to explain that
XADataSource should not do connection pooling but rather leave that to
some TM layer that should hide the XA code and only present DataSource
and Connection to the application programmer.

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

uuuh... you're right but if I call twice XAConnection.getConnection()
without closing the returned Connection in-between, you code manages
to see that and throws an SQLException. Maybe not the best of breed
implementation fo that case but good enough because at least it avoids
corruption.

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

Agreed, see my rant about XADataSource and DataSource above, I hope I
better explained what I had in mind this time. :-)

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

That would be good enough for me, at least for now.

Ludovic