DBCP: validationQuery Problems

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

DBCP: validationQuery Problems

Tim Patton
I'm using DBCP with the JTDS SQL driver.  I seem to be having a problem
where the validation query is not always running (I assume).  Basically I
have a pool of connections that have sat idle for hours; the server has most
likely shut them down by now.  When I execute an update I get
"java.sql.SQLException: I/O Error: Connection reset by peer: socket write
error".  However, it is my understanding that before returning a connection,
the pool should run the validation query and make sure it still works.  This
does not seem to be the case.  Is there any way to guarantee this runs?  I
have set the validation query to a working, non null value, and I always get
a new connection when executing any SQL, as well as always closing the
connection when I am done.

 

Tim

Reply | Threaded
Open this post in threaded view
|

RE: DBCP: validationQuery Problems

Sitowitz, Paul
Tim,

In addition to setting the validation query, you will ALSO need to
configure the pool to perform "validate on return". You can configure
validation to occur upon borrowing connections, returning connections,
and during the time when connections sit idle in the pool.

Check out the online JavaDocs for GenericObjectPool and
GenericKeyedObjectPool for more of the details and specifics:

http://jakarta.apache.org/commons/pool/apidocs/

Paul

-----Original Message-----
From: Tim Patton [mailto:[hidden email]]
Sent: Wednesday, November 16, 2005 11:55 AM
To: [hidden email]
Subject: DBCP: validationQuery Problems

I'm using DBCP with the JTDS SQL driver.  I seem to be having a problem
where the validation query is not always running (I assume).  Basically
I
have a pool of connections that have sat idle for hours; the server has
most
likely shut them down by now.  When I execute an update I get
"java.sql.SQLException: I/O Error: Connection reset by peer: socket
write
error".  However, it is my understanding that before returning a
connection,
the pool should run the validation query and make sure it still works.
This
does not seem to be the case.  Is there any way to guarantee this runs?
I
have set the validation query to a working, non null value, and I always
get
a new connection when executing any SQL, as well as always closing the
connection when I am done.

 

Tim


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: DBCP: validationQuery Problems

Tim Patton
Thanks for the link, should that be mentioned in the DBCP docs somewhere?
That seems to be an important omission.

Tim

-----Original Message-----
From: Sitowitz, Paul [mailto:[hidden email]]
Sent: Wednesday, November 16, 2005 12:05 PM
To: Jakarta Commons Users List
Subject: RE: DBCP: validationQuery Problems

Tim,

In addition to setting the validation query, you will ALSO need to
configure the pool to perform "validate on return". You can configure
validation to occur upon borrowing connections, returning connections,
and during the time when connections sit idle in the pool.

Check out the online JavaDocs for GenericObjectPool and
GenericKeyedObjectPool for more of the details and specifics:

http://jakarta.apache.org/commons/pool/apidocs/

Paul

-----Original Message-----
From: Tim Patton [mailto:[hidden email]]
Sent: Wednesday, November 16, 2005 11:55 AM
To: [hidden email]
Subject: DBCP: validationQuery Problems

I'm using DBCP with the JTDS SQL driver.  I seem to be having a problem
where the validation query is not always running (I assume).  Basically
I
have a pool of connections that have sat idle for hours; the server has
most
likely shut them down by now.  When I execute an update I get
"java.sql.SQLException: I/O Error: Connection reset by peer: socket
write
error".  However, it is my understanding that before returning a
connection,
the pool should run the validation query and make sure it still works.
This
does not seem to be the case.  Is there any way to guarantee this runs?
I
have set the validation query to a working, non null value, and I always
get
a new connection when executing any SQL, as well as always closing the
connection when I am done.

 

Tim


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: DBCP: validationQuery Problems

Sitowitz, Paul
In reply to this post by Tim Patton
This is functionality specific to the 'Commons Pool' components. Since
DBCP leverages the 'Pool' components, you kind of need to be familiar
with both. The Pool components provide pooling of Objects in general
whereas DBCP is primarily concerned with pooling of java.sql.Connection
and java.sql.PreparedStatement specifically.

-----Original Message-----
From: Tim Patton [mailto:[hidden email]]
Sent: Wednesday, November 16, 2005 12:12 PM
To: 'Jakarta Commons Users List'
Subject: RE: DBCP: validationQuery Problems

Thanks for the link, should that be mentioned in the DBCP docs
somewhere?
That seems to be an important omission.

Tim

-----Original Message-----
From: Sitowitz, Paul [mailto:[hidden email]]
Sent: Wednesday, November 16, 2005 12:05 PM
To: Jakarta Commons Users List
Subject: RE: DBCP: validationQuery Problems

Tim,

In addition to setting the validation query, you will ALSO need to
configure the pool to perform "validate on return". You can configure
validation to occur upon borrowing connections, returning connections,
and during the time when connections sit idle in the pool.

Check out the online JavaDocs for GenericObjectPool and
GenericKeyedObjectPool for more of the details and specifics:

http://jakarta.apache.org/commons/pool/apidocs/

Paul

-----Original Message-----
From: Tim Patton [mailto:[hidden email]]
Sent: Wednesday, November 16, 2005 11:55 AM
To: [hidden email]
Subject: DBCP: validationQuery Problems

I'm using DBCP with the JTDS SQL driver.  I seem to be having a problem
where the validation query is not always running (I assume).  Basically
I
have a pool of connections that have sat idle for hours; the server has
most
likely shut them down by now.  When I execute an update I get
"java.sql.SQLException: I/O Error: Connection reset by peer: socket
write
error".  However, it is my understanding that before returning a
connection,
the pool should run the validation query and make sure it still works.
This
does not seem to be the case.  Is there any way to guarantee this runs?
I
have set the validation query to a working, non null value, and I always
get
a new connection when executing any SQL, as well as always closing the
connection when I am done.

 

Tim


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: DBCP: validationQuery Problems

Tim Patton
I guess I meant as more of a "see also" for people coming in who are new to
this and (like me) were just skimming the docs and examples to get running.

Tim

-----Original Message-----
From: Sitowitz, Paul [mailto:[hidden email]]
Sent: Wednesday, November 16, 2005 12:16 PM
To: Jakarta Commons Users List
Subject: RE: DBCP: validationQuery Problems

This is functionality specific to the 'Commons Pool' components. Since
DBCP leverages the 'Pool' components, you kind of need to be familiar
with both. The Pool components provide pooling of Objects in general
whereas DBCP is primarily concerned with pooling of java.sql.Connection
and java.sql.PreparedStatement specifically.

-----Original Message-----
From: Tim Patton [mailto:[hidden email]]
Sent: Wednesday, November 16, 2005 12:12 PM
To: 'Jakarta Commons Users List'
Subject: RE: DBCP: validationQuery Problems

Thanks for the link, should that be mentioned in the DBCP docs
somewhere?
That seems to be an important omission.

Tim

-----Original Message-----
From: Sitowitz, Paul [mailto:[hidden email]]
Sent: Wednesday, November 16, 2005 12:05 PM
To: Jakarta Commons Users List
Subject: RE: DBCP: validationQuery Problems

Tim,

In addition to setting the validation query, you will ALSO need to
configure the pool to perform "validate on return". You can configure
validation to occur upon borrowing connections, returning connections,
and during the time when connections sit idle in the pool.

Check out the online JavaDocs for GenericObjectPool and
GenericKeyedObjectPool for more of the details and specifics:

http://jakarta.apache.org/commons/pool/apidocs/

Paul

-----Original Message-----
From: Tim Patton [mailto:[hidden email]]
Sent: Wednesday, November 16, 2005 11:55 AM
To: [hidden email]
Subject: DBCP: validationQuery Problems

I'm using DBCP with the JTDS SQL driver.  I seem to be having a problem
where the validation query is not always running (I assume).  Basically
I
have a pool of connections that have sat idle for hours; the server has
most
likely shut them down by now.  When I execute an update I get
"java.sql.SQLException: I/O Error: Connection reset by peer: socket
write
error".  However, it is my understanding that before returning a
connection,
the pool should run the validation query and make sure it still works.
This
does not seem to be the case.  Is there any way to guarantee this runs?
I
have set the validation query to a working, non null value, and I always
get
a new connection when executing any SQL, as well as always closing the
connection when I am done.

 

Tim


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]