You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jonathan Pierce <jo...@gmail.com> on 2014/03/25 13:05:22 UTC
PooledConnection.getConnection - Tomcat JDBC Pool
I am trying to use the tomcat jdbc pool library (outside of tomcat)
along with the Apache Aries Transaction library in an OSGi environment
to handle distributed transactions.
One of the classes (XADataSourceEnlistingWrapper) provided by the
Aries Transaction wrappers library is a DataSource wrapper that auto
enlists connections.
It appears that the Aries class is trying to call
XAConnection.getConnection with the expectation that the returned
Connection object will recycle connections when the close() method is
called (i.e. return the connection to the pool)
However, in the tomcat jdbc pooling library
PooledConnection.getConnection() (and by extension
XAConnection.getConnection()) seems to be returning the physical
connection. So the physical connection is getting closed without
being returned to the pool and I'm getting exceptions saying the pool
is empty after a few requests.
It looks like one of these libraries is implementing the interface
wrong (or its entirely possible I'm missing something). After reading
the J2SE docs for PooledConnection it seems like
PooledConnection.getConnection() should not return the physical
connection but a handle that when closed indicates the connection
should be returned to the pool. If that is the case the tomcat jdbc
pooling library handling the call incorrectly and its a bug.
I wanted to ask to post here before submitting a bug to the tracker in
case I'm missing something.
Thanks,
Jonathan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PooledConnection.getConnection - Tomcat JDBC Pool
Posted by Filip Hanik <fi...@hanik.com>.
Jonathan opened up the following bug
https://issues.apache.org/bugzilla/show_bug.cgi?id=56310
and I do believe our pool is incorrectly implementing the
ConnectionPoolDatasource. I do believe it shouldn't implement that
interface at all.
On Wed, Mar 26, 2014 at 10:41 AM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Jonathan,
>
> On 3/26/14, 9:16 AM, Pierce, Jonathan D wrote:
> > 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.
>
> That's clearly what the Javadoc says it should do. It looks like this
> is a case of a poorly-conceived API (IMHO).
>
> Filip clearly thinks this is a bug, so it will likely get a fix pretty
> quickly. It doesn't seem that hard to return a wrapper instead of the
> underlying object.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJTMwMuAAoJEBzwKT+lPKRYWNcQAJKcslDaOvFhAZZageXrvwSI
> Lh+tM5cajwxWaa/QE02uWf+zBErnhmC25hp7CkbEv3QcAKG0y1lHo4wa3PSyVWF6
> jcd1AkD2sUDh2+X65rOvlOJka1eW8MD8Tg7xWWN5uOmvMUJeesFupV2FmTy9uiri
> 2fqr3tfcSJ5OyXuvAHmPzL7U1mka11JKfG/plR3Hz2m0T1ROmrUXcUgESGFGFaVt
> BHtUeu8NecC+R89eNyU2Qa1j/aGNj894uwjYY8NgpojAbabFuMBjlc1BL5vYL5vx
> IUvtn+2P9mqdPY2SuDw6AXgz6dzDuAuog4wUdMl2jGJen6CmBhqXaUDKE6svmJaF
> hhXFUcgAXzyXSigQrbrMcSwvD7llRqOSyXdjCXYoFr0skZ34tDRmaPTx0JSAd1Dt
> Y7Wk/IPmIFM3VirpoqmtlMHeExIKsQEcPPiW71ZcCyY0F3eY2AGTHge/uRnGoMgc
> 47/7ppkIwyTm7U267/I1KQoGIqzO4NFD9COdmEDWNj4mINXo8iXnC595BGOkq6Ub
> eOJzA1PIWtqLssuXEovg4hia6JR//ctz56oEKuGHwnTqE1OP9RBmgUKM2jKoFo0b
> uxNulNj65aFf/Fvodenw4bpKQZciY8hSVCY7nLf316pXoNArsacQuSz7xEfQvZhE
> soK4sDPgR1AL+d78HLqh
> =WECl
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: PooledConnection.getConnection - Tomcat JDBC Pool
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jonathan,
On 3/26/14, 9:16 AM, Pierce, Jonathan D wrote:
> 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.
That's clearly what the Javadoc says it should do. It looks like this
is a case of a poorly-conceived API (IMHO).
Filip clearly thinks this is a bug, so it will likely get a fix pretty
quickly. It doesn't seem that hard to return a wrapper instead of the
underlying object.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTMwMuAAoJEBzwKT+lPKRYWNcQAJKcslDaOvFhAZZageXrvwSI
Lh+tM5cajwxWaa/QE02uWf+zBErnhmC25hp7CkbEv3QcAKG0y1lHo4wa3PSyVWF6
jcd1AkD2sUDh2+X65rOvlOJka1eW8MD8Tg7xWWN5uOmvMUJeesFupV2FmTy9uiri
2fqr3tfcSJ5OyXuvAHmPzL7U1mka11JKfG/plR3Hz2m0T1ROmrUXcUgESGFGFaVt
BHtUeu8NecC+R89eNyU2Qa1j/aGNj894uwjYY8NgpojAbabFuMBjlc1BL5vYL5vx
IUvtn+2P9mqdPY2SuDw6AXgz6dzDuAuog4wUdMl2jGJen6CmBhqXaUDKE6svmJaF
hhXFUcgAXzyXSigQrbrMcSwvD7llRqOSyXdjCXYoFr0skZ34tDRmaPTx0JSAd1Dt
Y7Wk/IPmIFM3VirpoqmtlMHeExIKsQEcPPiW71ZcCyY0F3eY2AGTHge/uRnGoMgc
47/7ppkIwyTm7U267/I1KQoGIqzO4NFD9COdmEDWNj4mINXo8iXnC595BGOkq6Ub
eOJzA1PIWtqLssuXEovg4hia6JR//ctz56oEKuGHwnTqE1OP9RBmgUKM2jKoFo0b
uxNulNj65aFf/Fvodenw4bpKQZciY8hSVCY7nLf316pXoNArsacQuSz7xEfQvZhE
soK4sDPgR1AL+d78HLqh
=WECl
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: PooledConnection.getConnection - Tomcat JDBC Pool
Posted by "Pierce, Jonathan D" <jo...@chase.com>.
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.Caldarale@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:chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: PooledConnection.getConnection - Tomcat JDBC Pool
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Christopher Schultz [mailto:chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PooledConnection.getConnection - Tomcat JDBC Pool
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jonathan,
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.
> This seems to jive with the documentation on
> PooledConnection.close
> (http://docs.oracle.com/javase/6/docs/api/javax/sql/PooledConnection.html):
>
>
>
"Closes the physical connection that this PooledConnection object
> represents. An application never calls this method directly; it is
> called by the connection pool module, or manager. See the
> interface description for more information."
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. Without any (English)
documentation, I would have expected the getConnection() method to
return the underlying connection -- the physical connection.
I wonder if that's the mistake that's been made, here.
> The reason I'm using the library outside of Tomcat is because I
> need a connection pooling library, and I'm running in an OSGi
> environment (not a Java Servlet Container). I came across
> tomcat-jdbc and after reading the documentation and doing some
> research it seemed like an improved drop in replacement for Apache
> Commons DBCP.
>
> We have been using it for over a year without problem. Only
> recently when we tried to implement distributed transactions have
> we run into any issues.
tomcat-pool should work perfectly fine outside of a Tomcat instance. I
think John just didn't realize that it was largely independent of
Tomcat itself.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTMeHAAAoJEBzwKT+lPKRYPk8QAMTe22Jz2TyE1oy4AppTDzKf
bJK8a+uOxH8C8UaBtBqP2V5Sxc8/Ys2nC6SHOSJpMEEDoLrcoOQhuvhzQc7LyW4W
vEPkf2xhoPmQq9V5Ho2Uy9nBpB2hL20vfPCjoFcjEldG2tCFF8LawsyJW5W/y8Rt
YuDmNlw8bvx6bcaL7qYkMb0+wdB19iRs3FGAXBBllg1GnkmcuwNa4u9cxfaPQSaV
gYvQ+kWerMI8fNfokRD3I+mutTjKCsX+imTFCrIf1TZiJJjHX8NEvsko0/lUaEUI
AvrJv6uru8wuuT8uSpk86WN4gaDA80aIwJONMH5IfEp8FVF0B8yTMHbRrCg/C9OF
BoeMkf2iAHBCz4PZULJxMm6QxGmeyyhf4MCXEwGFhS6EQLS6+QqB00mEIQsee7oc
FYRfrEwsHs59OMH9LaPGBg6C0cA6XyGSKN2lyHGaEnSULmSS1vVEmu7fp2pXTlEd
Cd+bq7GgXdZrq15Yc8DM/Qc9iv7cSD4ObCiO596JyjpYi8BB+yRw8GTdiSi0w4jS
LK3zMNxms+nIZppi8ckFCIWv0G8hv6Nf9ZzfU64ycH6BT6IxFSGr3UP8mpsNB1Q3
RkEpxFfSaW5LGW79WGg8NEvNUjCABIROvycs93cBecLyZHOOCU+QzunkXU27l6UV
zYlyW1MEKJY5jKbKNCAr
=tjsR
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: PooledConnection.getConnection - Tomcat JDBC Pool
Posted by "Pierce, Jonathan D" <jo...@chase.com>.
I've created Bug 56310 for this issue.
Jonathan
-----Original Message-----
From: Pierce, Jonathan D
Sent: Tuesday, March 25, 2014 10:54 AM
To: Tomcat Users List
Subject: RE: PooledConnection.getConnection - Tomcat JDBC Pool
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.
This seems to jive with the documentation on PooledConnection.close (http://docs.oracle.com/javase/6/docs/api/javax/sql/PooledConnection.html):
"Closes the physical connection that this PooledConnection object represents. An application never calls this method directly; it is called by the connection pool module, or manager.
See the interface description for more information."
The reason I'm using the library outside of Tomcat is because I need a connection pooling library, and I'm running in an OSGi environment (not a Java Servlet Container).
I came across tomcat-jdbc and after reading the documentation and doing some research it seemed like an improved drop in replacement for Apache Commons DBCP.
We have been using it for over a year without problem. Only recently when we tried to implement distributed transactions have we run into any issues.
I will create a bug in the bug tracker.
Jonathan
-----Original Message-----
From: John Smith [mailto:tomcat.random@gmail.com]
Sent: Tuesday, March 25, 2014 10:42 AM
To: Tomcat Users List
Subject: Re: PooledConnection.getConnection - Tomcat JDBC Pool
On Tue, Mar 25, 2014 at 9:54 AM, Filip Hanik <fi...@hanik.com> wrote:
> Please open a bug, and we will get this taken care of. I do have one
> question,Aries library, on which call does it expect to return the
> connection to the pool? XAConnection.close() or
> XAConnection.getConnection().close(); ?
>
>
Jonathan, Filip,
If it is a bug then my answer is way off the mark. I'm sorry. If it's not a problem, could you explain, in this case, what acts as the connection pool manager when the Tomcat jdbc pool library is used outside of Tomcat?
Best,
John
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: PooledConnection.getConnection - Tomcat JDBC Pool
Posted by "Pierce, Jonathan D" <jo...@chase.com>.
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.
This seems to jive with the documentation on PooledConnection.close (http://docs.oracle.com/javase/6/docs/api/javax/sql/PooledConnection.html):
"Closes the physical connection that this PooledConnection object represents. An application never calls this method directly; it is called by the connection pool module, or manager.
See the interface description for more information."
The reason I'm using the library outside of Tomcat is because I need a connection pooling library, and I'm running in an OSGi environment (not a Java Servlet Container).
I came across tomcat-jdbc and after reading the documentation and doing some research it seemed like an improved drop in replacement for Apache Commons DBCP.
We have been using it for over a year without problem. Only recently when we tried to implement distributed transactions have we run into any issues.
I will create a bug in the bug tracker.
Jonathan
-----Original Message-----
From: John Smith [mailto:tomcat.random@gmail.com]
Sent: Tuesday, March 25, 2014 10:42 AM
To: Tomcat Users List
Subject: Re: PooledConnection.getConnection - Tomcat JDBC Pool
On Tue, Mar 25, 2014 at 9:54 AM, Filip Hanik <fi...@hanik.com> wrote:
> Please open a bug, and we will get this taken care of. I do have one
> question,Aries library, on which call does it expect to return the
> connection to the pool? XAConnection.close() or
> XAConnection.getConnection().close(); ?
>
>
Jonathan, Filip,
If it is a bug then my answer is way off the mark. I'm sorry. If it's not a problem, could you explain, in this case, what acts as the connection pool manager when the Tomcat jdbc pool library is used outside of Tomcat?
Best,
John
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PooledConnection.getConnection - Tomcat JDBC Pool
Posted by John Smith <to...@gmail.com>.
On Tue, Mar 25, 2014 at 9:54 AM, Filip Hanik <fi...@hanik.com> wrote:
> Please open a bug, and we will get this taken care of. I do have one
> question,Aries library, on which call does it expect to return the
> connection to the pool? XAConnection.close() or
> XAConnection.getConnection().close(); ?
>
>
Jonathan, Filip,
If it is a bug then my answer is way off the mark. I'm sorry. If it's not a
problem, could you explain, in this case, what acts as the connection pool
manager when the Tomcat jdbc pool library is used outside of Tomcat?
Best,
John
Re: PooledConnection.getConnection - Tomcat JDBC Pool
Posted by Filip Hanik <fi...@hanik.com>.
Please open a bug, and we will get this taken care of. I do have one
question,Aries library, on which call does it expect to return the
connection to the pool? XAConnection.close() or
XAConnection.getConnection().close(); ?
On Tue, Mar 25, 2014 at 6:05 AM, Jonathan Pierce <jo...@gmail.com>wrote:
> I am trying to use the tomcat jdbc pool library (outside of tomcat)
> along with the Apache Aries Transaction library in an OSGi environment
> to handle distributed transactions.
>
> One of the classes (XADataSourceEnlistingWrapper) provided by the
> Aries Transaction wrappers library is a DataSource wrapper that auto
> enlists connections.
>
> It appears that the Aries class is trying to call
> XAConnection.getConnection with the expectation that the returned
> Connection object will recycle connections when the close() method is
> called (i.e. return the connection to the pool)
>
> However, in the tomcat jdbc pooling library
> PooledConnection.getConnection() (and by extension
> XAConnection.getConnection()) seems to be returning the physical
> connection. So the physical connection is getting closed without
> being returned to the pool and I'm getting exceptions saying the pool
> is empty after a few requests.
>
> It looks like one of these libraries is implementing the interface
> wrong (or its entirely possible I'm missing something). After reading
> the J2SE docs for PooledConnection it seems like
> PooledConnection.getConnection() should not return the physical
> connection but a handle that when closed indicates the connection
> should be returned to the pool. If that is the case the tomcat jdbc
> pooling library handling the call incorrectly and its a bug.
>
> I wanted to ask to post here before submitting a bug to the tracker in
> case I'm missing something.
>
> Thanks,
> Jonathan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: PooledConnection.getConnection - Tomcat JDBC Pool
Posted by John Smith <to...@gmail.com>.
> If that is the case the tomcat jdbc
> pooling library handling the call incorrectly and its a bug.
>
I'd be suspect of this. Are you actually using *org.apache.tomcat.jdbc.pool*?
Since it's a Tomcat module it seems an odd choice to use outside of Tomcat.
http://docs.oracle.com/javase/7/docs/api/javax/sql/PooledConnection.html
*The connection pool manager, typically the application server, maintains a
pool of PooledConnection objects. If there is a PooledConnection object
available in the pool, the connection pool manager returns a Connection
object that is a handle to that physical connection. If no PooledConnection
object is available, the connection pool manager calls the
ConnectionPoolDataSource method getPoolConnection to create a new physical
connection. The JDBC driver implementing ConnectionPoolDataSource creates a
new PooledConnection object and returns a handle to it. *
My emphasis there. Just using the tomcat jdbc classes doesn't guarantee you
have a pool. It does guarantee you'll get a connection, however it won't be
pooled if there isn't one. Am I misunderstanding that "outside of Tomcat"
means you're running Tomcat, but have some non-webapp application that's
trying to use the JNDI datasource? Or are you not running Tomcat at all?
Best,
John