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: ma...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org >