You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Amish Shah <as...@opnet.com> on 2012/07/25 16:01:32 UTC
[dbcp] prepared statement caching when connections are closed but
connection pool still has connection
Does the DBCP support prepared statement caching in the following condition
1) connection is opened from connection pool
2) Prepared statement are used
3) Connection is closed but returned to connection pool
If we reuse the connection from the connection pool is there a way the
prepared statement from step #2,
could be used without parsing again.
What I am seeing is that prepared statement are being parsed again?
We are using version of DBCP 1.2.1
Any help/response would be good.
Amish Shah
OPNET Technology
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [dbcp] prepared statement caching when connections are closed but
connection pool still has connection
Posted by Gary Gregory <ga...@gmail.com>.
Note that if you must use 1.2 you should test with the latest version
from that branch which is 1.2.2. We are on 1.4.x for current
development.
Gary
On Jul 25, 2012, at 10:16, Amish Shah <as...@opnet.com> wrote:
>
> Does the DBCP support prepared statement caching in the following condition
> 1) connection is opened from connection pool
> 2) Prepared statement are used
> 3) Connection is closed but returned to connection pool
>
> If we reuse the connection from the connection pool is there a way the prepared statement from step #2,
> could be used without parsing again.
>
>
> What I am seeing is that prepared statement are being parsed again?
> We are using version of DBCP 1.2.1
>
> Any help/response would be good.
>
> Amish Shah
> OPNET Technology
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
RE: [dbcp] prepared statement caching when connections are closed
but connection pool still has connection
Posted by Martin Gainty <mg...@hotmail.com>.
Folks-
in the case Of DelegatingStatement Statement iterator will close open Statement handles during the passivate stage of a DBCP connection_pool close..here is the code:
protected void passivate() throws SQLException {
try {
// The JDBC spec requires that a Connection close any open
// Statement's when it is closed.
// DBCP-288. Not all the traced objects will be statements
List traces = getTrace();
if(traces != null) {
Iterator traceIter = traces.iterator();
while (traceIter.hasNext()) {
Object trace = traceIter.next();
if (trace instanceof Statement) {
((Statement) trace).close();
PoolableConnectionFactory does close old statement handles during connection initialiasation as seen here
protected void initializeConnection(Connection conn) throws SQLException {
Collection sqls = _connectionInitSqls;
if(conn.isClosed()) {
throw new SQLException("initializeConnection: connection closed");
}
if(null != sqls) {
Statement stmt = null;
try {
stmt = conn.createStatement();
for (Iterator iterator = sqls.iterator(); iterator.hasNext();)
{
Object o = iterator.next();
if (o == null) {
throw new NullPointerException("null connectionInitSqls element");
}
// o might not be a String instance
String sql = o.toString();
stmt.execute(sql);
}
} finally {
if (stmt != null) {
try {
stmt.close();
PoolableConnectionFactory will also close statement handles during connection validation as evidenced here:
public void validateConnection(Connection conn) throws SQLException {
String query = _validationQuery;
if(conn.isClosed()) {
throw new SQLException("validateConnection: connection closed");
}
if(null != query) {
Statement stmt = null;
ResultSet rset = null;
try {
stmt = conn.createStatement();
if (_validationQueryTimeout > 0) {
stmt.setQueryTimeout(_validationQueryTimeout);
}
rset = stmt.executeQuery(query);
if(!rset.next()) {
throw new SQLException("validationQuery didn't return a row");
}
} finally {
if (rset != null) {
try {
rset.close();
} catch(Exception t) {
// ignored
}
}
if (stmt != null) {
try {
stmt.close();
PoolingConnection does close Statement handles thru the innermostDelegate object as seen here
public void destroyObject(Object key, Object obj) throws Exception {
if(obj instanceof DelegatingPreparedStatement) {
((DelegatingPreparedStatement)obj).getInnermostDelegate().close();
} else {
((PreparedStatement)obj).close();
}
}
you will see identical behaviour with concrete class for PooledConnection .\cpdsadapter\PooledConnectionImpl which checks if the statement handle is Delegating or Prepared
public void destroyObject(Object key, Object obj) throws Exception {
//_openPstmts--;
if (obj instanceof DelegatingPreparedStatement) {
((DelegatingPreparedStatement) obj).getInnermostDelegate().close();
} else {
((PreparedStatement) obj).close();
}
}
does this conform to your understanding ?
Martin
______________________________________________
Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Ez az
üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy
jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának
készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és
semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek
könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet
ezen üzenet tartalma miatt.
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> Date: Fri, 27 Jul 2012 12:53:49 +0100
> From: markt@apache.org
> To: user@commons.apache.org
> Subject: Re: [dbcp] prepared statement caching when connections are closed but connection pool still has connection
>
> On 25/07/2012 15:01, Amish Shah wrote:
> >
> > Does the DBCP support prepared statement caching in the following condition
> > 1) connection is opened from connection pool
> > 2) Prepared statement are used
> > 3) Connection is closed but returned to connection pool
> >
> > If we reuse the connection from the connection pool is there a way the
> > prepared statement from step #2,
> > could be used without parsing again.
> >
> >
> > What I am seeing is that prepared statement are being parsed again?
> > We are using version of DBCP 1.2.1
> >
> > Any help/response would be good.
>
> I took a quick look at the source code. The DBCP code is a bit of a maze
> and I'd need to test it to be sure but I think the statement cache is
> retained while the connection is checked out but cleared when the
> connection is returned. I suspect you'll be able to check this faster
> than I can.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
Re: [dbcp] prepared statement caching when connections are closed
but connection pool still has connection
Posted by Mark Thomas <ma...@apache.org>.
On 25/07/2012 15:01, Amish Shah wrote:
>
> Does the DBCP support prepared statement caching in the following condition
> 1) connection is opened from connection pool
> 2) Prepared statement are used
> 3) Connection is closed but returned to connection pool
>
> If we reuse the connection from the connection pool is there a way the
> prepared statement from step #2,
> could be used without parsing again.
>
>
> What I am seeing is that prepared statement are being parsed again?
> We are using version of DBCP 1.2.1
>
> Any help/response would be good.
I took a quick look at the source code. The DBCP code is a bit of a maze
and I'd need to test it to be sure but I think the statement cache is
retained while the connection is checked out but cleared when the
connection is returned. I suspect you'll be able to check this faster
than I can.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org