I agree that it is counter-intuitive. I also agree that the application should not need to use the PooledConnection interface.
However, XAConnection is needed to be used by a transaction manager, and it extends PooledConnection. So if I understancd correctly, an application gets an XAConnection from an XADataSource, it does all of the necessary XA boiler plate, and then calls XAConnection.getConnection() to get the java.sql.Connection object that will be used for all of the standard JDBC calls. If the application is using a connection pool, then I think XAConnection.getConnection should NOT return the physical connection, but a handle that when closed will return the connection to the pool. Jonathan -----Original Message----- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Tuesday, March 25, 2014 4:17 PM To: Tomcat Users List Subject: RE: PooledConnection.getConnection - Tomcat JDBC Pool > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Subject: Re: PooledConnection.getConnection - Tomcat JDBC Pool > On 3/25/14, 10:53 AM, Pierce, Jonathan D wrote: > > In the Aries class, the expectation is that > > XAConnection.getConnection().close() will return the connection to > > the pool, and that XAConnection.close() would close the physical > > connection. > That sounds counter intuitive to me. Agreed. The application should have no knowledge of or concern with the physical connections. > What's odd is that PooledConnection.getConnection() is documented to > return a discardable wrapper of the current connection object. That's > unexpected as far as I'm concerned. No, an instance of PooledConnection is the so-called physical connection object. Note that PooledConnection is not to be used by the application, but rather only by the pool manager to get connections from the JDBC driver. No application writer should be looking at the PooledConnection interface - it is of no interest to the app. - Chuck --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
