You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2013/11/20 14:21:58 UTC
Re: [OT] Curious difference in connection behaviour on database side
DBCP vs. JDBC?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Rainer,
On 11/20/13, 2:36 AM, Rainer Frey (Inxmail GmbH) wrote:
>
> On 19.11.2013, at 14:45, Mark Thomas <ma...@apache.org> wrote:
>
>> On 19/11/2013 13:32, Carl Boberg wrote:
>>
>>> I have here an example of the way we close from the
>>> application, (the devs have named it dispose). From my
>>> untrained non java dev eye we do not seem to be doing
>>> statement.Close(); and Im curious if that might be the issue?
>>> If so, why does DBCP handle it nicely and not JDBC?
>>
>> Commons DBCP tracks Statements and ResultSets when they are
>> created and closes the associated Statements and ResultSets when
>> the connection that created them is returned to the pool.
>>
>> Tomcat's JDBC pool does not do this. This is one of the reasons
>> that Commons DBCP has a larger code base.
>
> JDBC spec states (9.4.4):
>
>> An application calls the method Connection.close() to indicate
>> that it has finished using a connection. All Statement objects
>> created from a given Connection object will be closed when the
>> close method for the Connection object is called.
>
> Javadoc of Connection.close() and Statement.close() at least imply
> that as well. ResultSet’s Javadoc explicitly states that a
> ResultSet is closed when the statement is closed.
FWIW, Connection.close also states this:
"
Releases this Connection object's database and JDBC resources
immediately instead of waiting for them to be automatically released.
"
Does that mean that all connection pools by design are in direct
violation of the JDBC spec?
> AFAICT the JDBC pool uses (as most connection pools) the
> Connection.close() as means to return a connection to the pool.
> While I understand that the semantics of completely closing a
> standalone connection and returning a pooled connection is
> different, this behavior is still a (presumably deliberate)
> violation of the spec, and makes the usage non-transparent to the
> application code.
>
> IMO this should be clearly stated in the JDBC pool’s docs, in an
> easily visible way.
+1
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSjLd2AAoJEBzwKT+lPKRYNNQP/3cfd2vtsqPdLRYca5yVg7cv
e+6nLlZtzuCWRA2V0DFS7jLm433qz3ADyvnwlP03luusiAt4ShByQEAIu173Zya3
niQ49e/yJ9R2xBcoyat/Z1Q0YqSjLxh+tniy/RuK/sh6zPhOXL2EqxtRB1I4xNc4
ZywlWdjkqUr5hflUTvfsGv3E+X+b+WhBTxsoKbWK/2ZIWkd7XA9Cyv95qZ/F1srI
EQEshMm0uL81CTI7EwsjxqdlJMyAKNQaeVlJnNz/mEtSHeh0Yiv+nBkJ71vcUz87
UtNpSJtCzOpKye6MxOsaTeq8HnJhohA6sbP9EAuAoqLJv+MFlEi0FuQ7/+eTX3vS
2kmielRWIqNFzXZvdNmq2bAvb66H414aGLy5UIjfce7hpYokNGueBZQPtYZgGkyr
xV6h7Wj37hwGgJt4eVRe9Jg+UVgalhmdOpGmpjAY7XM1GpWq5P0ZwK8j8fw7smnF
xPSskG2ZRCFUkY2VXy11DPxA8bQHTiZoiDwZAumdDRmBmujG3MSogLL6X/b3mDtZ
OnqtJ9UC3v15KNTgZDLymK+UKQ+l6SkWOZeS4/R/vOpvnOe/sVboKEGGWBSoMVq6
VRaTv+l3Qi3yJ5K0R4Xauvd8PXO0606xqW3DVqEo/1BOqTap29BxFI2SxuoJUqlX
VLxLOnTimqEeXydZ7dP4
=Tm7/
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Curious difference in connection behaviour on database
side DBCP vs. JDBC?
Posted by "Rainer Frey (Inxmail GmbH)" <Ra...@inxmail.de>.
On 22.11.2013, at 02:20, Christopher Schultz <ch...@christopherschultz.net> wrote:
>> I also think that this is a justifiable spec violation, and all I’m
>> asking is that this fact is shown more prominently, esp. as JDBC
>> pool is advertised as a drop-in replacement for DBCP.
>
> Fair enough. Care you file a documentation bug and possibly provide a
> patch?
Will do, not sure I’ll get to it before the weekend though.
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Curious difference in connection behaviour on database side
DBCP vs. JDBC?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Rainer,
On 11/21/13, 2:18 AM, Rainer Frey (Inxmail GmbH) wrote:
>
> On 20.11.2013, at 14:21, Christopher Schultz
> <ch...@christopherschultz.net> wrote:
>
>> Rainer, FWIW, Connection.close also states this:
>>
>> " Releases this Connection object's database and JDBC resources
>> immediately instead of waiting for them to be automatically
>> released. "
>>
>> Does that mean that all connection pools by design are in direct
>> violation of the JDBC spec?
>
> I assume you’re referring to the "Releases this Connection object's
> database resources” part, then yes, they’re in violation of the
> letter of the API spec. I’m not sure whether the Javadoc is
> regarded as binding as the spec document though. And following the
> letter would indeed defy the very purpose of the pool.
>
> The other pools that I know do free the JDBC resources though. And
> that’s the part of the behavior that is really visible to the
> application. (And yes, Javadoc says it is best practice to
> explicitly close the JDBC resources as early as possible, but it
> also states that one can get away with not doing so).
>
> I also think that this is a justifiable spec violation, and all I’m
> asking is that this fact is shown more prominently, esp. as JDBC
> pool is advertised as a drop-in replacement for DBCP.
Fair enough. Care you file a documentation bug and possibly provide a
patch?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSjrFXAAoJEBzwKT+lPKRYTPMQAI/9LkWMM9h/VdmQdqIRiWpo
DUZJhzTDs+BqVo5pjaomEpjIcUsjckyqOuvdJ2Fp1b2maUAFJd8E3DiqEQpYw4Kq
5lyPhk3MxWLmrjg5yqdnQzUb7Ay0RFQcjlKzwJ1xVGaaBam0erwpUuwKCxuf/xZk
Svo2/Q+HxDPZeJfRetzGaBVfSCNW8eWKNQS0i0iJuFgLpvciesHb3YgTQC39ma/7
0JSOuwPvNX0+ulRVCYnXLUThhclO4mmWmnuo7RamAfx7hv+fKaKaZu1aI9eSrskn
kMtsly8vbc9W1WL38pO7EiDmufVEBdlE2Qhmb88kJnzCEsp9wNxK2qGTRFj6CNmA
KkGXXVag4B2z2ycHNmuxj4VS0y6RSxvhLsHAbiYaeitT8tpWkyxO0P+FOX4+Od86
cTR/iGyUQjUuVQ1wLMqsAlMNM0e28i9OkKmrOzNOjLnhre4RXH9Wd3f1tfwH5TBC
m3Ll9SFgmWPHQzLxpinp5XqmyJVl9KlMbaW8rB/6ribhPPXoULUQnIVdPFhm7r2n
zZ7QSYcBuW6fcqpM583VQJDmL/1dOaTcspRSWoBiRFVPq6SuIilaXjeIqNTf+SxQ
BKgRPAs+hZ5B9jS2v5rBfvLoUfBf1I8YmohGd4xG8ifbLhzZXHirakMJhiW045fW
ZYB3DK0svtw7+FkUKOId
=sux5
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Curious difference in connection behaviour on database
side DBCP vs. JDBC?
Posted by "Rainer Frey (Inxmail GmbH)" <Ra...@inxmail.de>.
On 20.11.2013, at 14:21, Christopher Schultz <ch...@christopherschultz.net> wrote:
> Rainer,
> FWIW, Connection.close also states this:
>
> "
> Releases this Connection object's database and JDBC resources
> immediately instead of waiting for them to be automatically released.
> "
>
> Does that mean that all connection pools by design are in direct
> violation of the JDBC spec?
I assume you’re referring to the "Releases this Connection object's database resources”
part, then yes, they’re in violation of the letter of the API spec. I’m not sure whether
the Javadoc is regarded as binding as the spec document though. And following the letter
would indeed defy the very purpose of the pool.
The other pools that I know do free the JDBC resources though. And that’s the part of the
behavior that is really visible to the application. (And yes, Javadoc says it is best practice
to explicitly close the JDBC resources as early as possible, but it also states that one
can get away with not doing so).
I also think that this is a justifiable spec violation, and all I’m asking is that this fact
is shown more prominently, esp. as JDBC pool is advertised as a drop-in replacement for DBCP.
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org