Atomikos Forum

T.E. not honoring provided XADataSource

I have consulted with my JDBC Guru, and we believe that a critical problem I'm encountering is due to Atomikos not honoring the provided XADataSource.

I understand that if Atomikos makes their own XADataSource, Atomikos may want or need to circumvent .close() methods which were implemented without the intention for them to be re-used.  But if somebody calls AtomikosDataSourceBean.setXaDataSource(), you should honor the implementation of the Connections returned by XADataSource.getXAConnection().getConnection().  My tests indicate that when I provide a XADataSource, Atomikos intercepts end user Connection.close() calls so that they never reach our correctly implemented close method.

Just say the word and I'll provide my trivial connection pool manager and a test driver that shows it works correctly; and a modified version of the driver that uses AtomikosDataSourceBean showing that my .close() calls do not invoke the close methods of the JDBC driver, and therefore bypass critical reset behavior.

Please correct me or advise.
Blaine Simpson Send private email
Friday, October 01, 2010
 
 
Me again.

A further point of evidence that intercepting close() from XADataSource-provided Connections is against the purpose and spirit of javax.sql design.  The objects from which you obtain the Connections, the XAConnections, are responsible for issuing ConnectionEvents and managing listeners for them.  It is impossible for these XAConnections to issue these events if you provide no means for them to know when closes occur.  More specifically, my tests show that Atomikos does not follow the API spec text for javax.sql.PooledConnection:

"When connection pooling is being done, the connection pool manager is notified because it has registered itself as a ConnectionEventListener object using the ConnectionPool method addConnectionEventListener."
[The class name "ConnectionPool" in this text is actually incorrect.  They should have written "PooledConnection", which of course includes its subclass "XAConnection"].

I haven't actually tested if Atomikos "registers", but if it does it is pointless since Atomikos never gives the XAConnect the opportunity to alert it or any other listeners.
Blaine Simpson Send private email
Friday, October 01, 2010
 
 
Thanks - case created to look at this in more detail. I know this used to be ok with our previous pools, but I need to check with the current one to be sure.
Guy Pardon Send private email
Monday, October 04, 2010
 
 
Doesn't look like there's much enthusiasm to provide javax.sql support as advertised, so I sat down to fix it myself, but got stumped by not having access to the source code (that issue is covered by different forum thread).  I don't want to work with old code and have to waste time with possible merge conflicts, etc.

If I can somehow get up-to-date source code soon, any tips would be appreciated, such as where it would be best to toggle the close-intercept.  It is not straight-forward finding the classes involved since you use non-public and anonymous java.sql.Connection wrappers with multiple levels of indirection in the instantiations... I hope to be able to track down with a debugger and searches, but it'll be time-consuming at best.
Blaine Simpson Send private email
Monday, October 18, 2010
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics