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

Hmmmm... indeed XADataSource is not subclass of the
ConnectionPoolDataSource, but the XAConnection is subclass of a
PooledConnection.... Grrr...

So we have to create two different classes - one for
ConnectionPoolDataSource and one for 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.

No, we have to compare the XADataSource and ConnectionPoolDataSource since
XAConnection happens to be subclass of PooledConnection (most likely only to
save the getConnection() method declaration), but anyway, there's nothing
about pooling in XADataSource.

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

Ok, accepted.

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

Hmmm... some side effect... :-)

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

Then we add this to the 2.1 and fix it in 2.2 where we planned to fix all
XA-related issues. Ok?

Thanks!
Roman