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
>
