commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Gainty <mgai...@hotmail.com>
Subject RE: [dbcp] prepared statement caching when connections are closed but connection pool still has connection
Date Fri, 27 Jul 2012 14:17:16 GMT

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
> 
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message