|Subject||Re: [Firebird-Java] Re: Two XA bugs|
> I think this is where you got it wrong. It's nowhere stated thatHmmmm... indeed XADataSource is not subclass of the
> 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.
ConnectionPoolDataSource, but the XAConnection is subclass of a
So we have to create two different classes - one for
ConnectionPoolDataSource and one for XADataSource.
> Look carefully at the javadocs of DataSource.getConnection andNo, we have to compare the XADataSource and ConnectionPoolDataSource since
> XADataSource.getXAConnection. Notice the subtle difference ? In the XA
> class, they used the word "physical" but not in the non-XA one.
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 DataSourceOk, accepted.
> - 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.
> uuuh... you're right but if I call twice XAConnection.getConnection()Hmmm... some side effect... :-)
> 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
> 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?