You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Brad Johnson <5f...@sneakemail.com> on 2003/09/24 23:47:06 UTC

JDBC AbandonedObjectPool and PoolableConnectionFactory

Hello,

I noticed the latest commit to AbandonedObjectPool.java in the Jakarta Commons DBCP project. The changes seem to fix some thread blocking that I have observed lately on our Tomcat uPortal app.

I tried out the new nightly (9/24/03) today, and I think another point of thread contention has been exposed when using the validate connection features of DBCP. I'm worried that if the validation query takes too long/hangs then all the other threads that want a connection will be blocked until it times out. Do you think I'm on the right track?

"Thread-43" daemon prio=1 tid=0x0x85215f8 nid=0x29be waiting for monitor entry
	[5b80b000..5b80c840]
        at org.apache.commons.dbcp.PoolableConnectionFactory.validateObject(PoolableConnectionFactory.java:316)
        - waiting to lock <0x45b85a98> (a org.apache.commons.dbcp.PoolableConnectionFactory)
        at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:833)

--- several threads like the above wait on the following to complete:

"Thread-98" daemon prio=1 tid=0x0x8691b10 nid=0x2a1d runnable [5c4ff000..5c501840]
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.read(SocketInputStream.java:129)
        at oracle.net.ns.Packet.receive(Unknown Source)
        at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)
        at oracle.net.ns.NetInputStream.read(Unknown Source)
        at oracle.net.ns.NetInputStream.read(Unknown Source)
        at oracle.net.ns.NetInputStream.read(Unknown Source)
        at oracle.jdbc.ttc7.MAREngine.unmarshalUB1(MAREngine.java:931)
        at oracle.jdbc.ttc7.MAREngine.unmarshalSB1(MAREngine.java:893)
        at oracle.jdbc.ttc7.v8Odscrarr.receive(v8Odscrarr.java:178)
        at oracle.jdbc.ttc7.TTC7Protocol.describe(TTC7Protocol.java:754)
        - locked <0x4dda5560> (a oracle.jdbc.ttc7.TTC7Protocol)
        at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteDescribe(TTC7Protocol.java:860)
        - locked <0x4dda5560> (a oracle.jdbc.ttc7.TTC7Protocol)
        at
oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java:2391)
        at
oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2672)
        at oracle.jdbc.driver.OracleStatement.executeQuery(OracleStatement.java:572)
        - locked <0x44f61438> (a oracle.jdbc.driver.OracleStatement)
        - locked <0x4e07b950> (a oracle.jdbc.driver.OracleConnection)
        at
org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:188)
        at
org.apache.commons.dbcp.PoolableConnectionFactory.validateConnection(PoolableConnectionFactory.java:338)
        - locked <0x45b85a98> (a org.apache.commons.dbcp.PoolableConnectionFactory)
        at
org.apache.commons.dbcp.PoolableConnectionFactory.validateObject(PoolableConnectionFactory.java:318)
        - locked <0x45b85a98> (a org.apache.commons.dbcp.PoolableConnectionFactory)
        at
org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:833)
----------------

Thanks,

Brad Johnson
Texas Tech University

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: JDBC AbandonedObjectPool and PoolableConnectionFactory

Posted by Dirk Verbeeck <di...@pandora.be>.
You can remove the synchronization of the validateObject method in 
PoolableConnectionFactory but be carefull.
If the query is slow because the database is overloaded then allowing 
more validationQueries will increase the problem.

For the next release I'm thinking about monitoring SQLExceptions thrown 
by the connection and invalidating the connection before it is returned 
to the pool.
This will cover "broken" connections. Combined with a 
"testOnBorrowOldConnection" it can replace the current "testOnBorrow".

Dirk

Brad Johnson wrote:

>Hello,
>
>I noticed the latest commit to AbandonedObjectPool.java in the Jakarta Commons DBCP project. The changes seem to fix some thread blocking that I have observed lately on our Tomcat uPortal app.
>
>I tried out the new nightly (9/24/03) today, and I think another point of thread contention has been exposed when using the validate connection features of DBCP. I'm worried that if the validation query takes too long/hangs then all the other threads that want a connection will be blocked until it times out. Do you think I'm on the right track?
>
<stacktrace removed>

>----------------
>
>Thanks,
>
>Brad Johnson
>Texas Tech University
>  
>




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: JDBC AbandonedObjectPool and PoolableConnectionFactory

Posted by Glenn Nielsen <gl...@mail.more.net>.
This should be fixed in CVS now.

Glenn

John McNally wrote:
> yes that looks like a correct observation.  The synchronization scope
> could be reduced.
> john mcnally
> 
> On Wed, 2003-09-24 at 14:47, Brad Johnson wrote:
> 
>>Hello,
>>
>>I noticed the latest commit to AbandonedObjectPool.java in the Jakarta Commons DBCP project. The changes seem to fix some thread blocking that I have observed lately on our Tomcat uPortal app.
>>
>>I tried out the new nightly (9/24/03) today, and I think another point of thread contention has been exposed when using the validate connection features of DBCP. I'm worried that if the validation query takes too long/hangs then all the other threads that want a connection will be blocked until it times out. Do you think I'm on the right track?
>>
>>"Thread-43" daemon prio=1 tid=0x0x85215f8 nid=0x29be waiting for monitor entry
>>	[5b80b000..5b80c840]
>>        at org.apache.commons.dbcp.PoolableConnectionFactory.validateObject(PoolableConnectionFactory.java:316)
>>        - waiting to lock <0x45b85a98> (a org.apache.commons.dbcp.PoolableConnectionFactory)
>>        at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:833)
>>
>>--- several threads like the above wait on the following to complete:
>>
>>"Thread-98" daemon prio=1 tid=0x0x8691b10 nid=0x2a1d runnable [5c4ff000..5c501840]
>>        at java.net.SocketInputStream.socketRead0(Native Method)
>>        at java.net.SocketInputStream.read(SocketInputStream.java:129)
>>        at oracle.net.ns.Packet.receive(Unknown Source)
>>        at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)
>>        at oracle.net.ns.NetInputStream.read(Unknown Source)
>>        at oracle.net.ns.NetInputStream.read(Unknown Source)
>>        at oracle.net.ns.NetInputStream.read(Unknown Source)
>>        at oracle.jdbc.ttc7.MAREngine.unmarshalUB1(MAREngine.java:931)
>>        at oracle.jdbc.ttc7.MAREngine.unmarshalSB1(MAREngine.java:893)
>>        at oracle.jdbc.ttc7.v8Odscrarr.receive(v8Odscrarr.java:178)
>>        at oracle.jdbc.ttc7.TTC7Protocol.describe(TTC7Protocol.java:754)
>>        - locked <0x4dda5560> (a oracle.jdbc.ttc7.TTC7Protocol)
>>        at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteDescribe(TTC7Protocol.java:860)
>>        - locked <0x4dda5560> (a oracle.jdbc.ttc7.TTC7Protocol)
>>        at
>>oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java:2391)
>>        at
>>oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2672)
>>        at oracle.jdbc.driver.OracleStatement.executeQuery(OracleStatement.java:572)
>>        - locked <0x44f61438> (a oracle.jdbc.driver.OracleStatement)
>>        - locked <0x4e07b950> (a oracle.jdbc.driver.OracleConnection)
>>        at
>>org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:188)
>>        at
>>org.apache.commons.dbcp.PoolableConnectionFactory.validateConnection(PoolableConnectionFactory.java:338)
>>        - locked <0x45b85a98> (a org.apache.commons.dbcp.PoolableConnectionFactory)
>>        at
>>org.apache.commons.dbcp.PoolableConnectionFactory.validateObject(PoolableConnectionFactory.java:318)
>>        - locked <0x45b85a98> (a org.apache.commons.dbcp.PoolableConnectionFactory)
>>        at
>>org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:833)
>>----------------
>>
>>Thanks,
>>
>>Brad Johnson
>>Texas Tech University
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>

Re: JDBC AbandonedObjectPool and PoolableConnectionFactory

Posted by Glenn Nielsen <gl...@mail.more.net>.
This should be fixed in CVS now.

Glenn

John McNally wrote:
> yes that looks like a correct observation.  The synchronization scope
> could be reduced.
> john mcnally
> 
> On Wed, 2003-09-24 at 14:47, Brad Johnson wrote:
> 
>>Hello,
>>
>>I noticed the latest commit to AbandonedObjectPool.java in the Jakarta Commons DBCP project. The changes seem to fix some thread blocking that I have observed lately on our Tomcat uPortal app.
>>
>>I tried out the new nightly (9/24/03) today, and I think another point of thread contention has been exposed when using the validate connection features of DBCP. I'm worried that if the validation query takes too long/hangs then all the other threads that want a connection will be blocked until it times out. Do you think I'm on the right track?
>>
>>"Thread-43" daemon prio=1 tid=0x0x85215f8 nid=0x29be waiting for monitor entry
>>	[5b80b000..5b80c840]
>>        at org.apache.commons.dbcp.PoolableConnectionFactory.validateObject(PoolableConnectionFactory.java:316)
>>        - waiting to lock <0x45b85a98> (a org.apache.commons.dbcp.PoolableConnectionFactory)
>>        at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:833)
>>
>>--- several threads like the above wait on the following to complete:
>>
>>"Thread-98" daemon prio=1 tid=0x0x8691b10 nid=0x2a1d runnable [5c4ff000..5c501840]
>>        at java.net.SocketInputStream.socketRead0(Native Method)
>>        at java.net.SocketInputStream.read(SocketInputStream.java:129)
>>        at oracle.net.ns.Packet.receive(Unknown Source)
>>        at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)
>>        at oracle.net.ns.NetInputStream.read(Unknown Source)
>>        at oracle.net.ns.NetInputStream.read(Unknown Source)
>>        at oracle.net.ns.NetInputStream.read(Unknown Source)
>>        at oracle.jdbc.ttc7.MAREngine.unmarshalUB1(MAREngine.java:931)
>>        at oracle.jdbc.ttc7.MAREngine.unmarshalSB1(MAREngine.java:893)
>>        at oracle.jdbc.ttc7.v8Odscrarr.receive(v8Odscrarr.java:178)
>>        at oracle.jdbc.ttc7.TTC7Protocol.describe(TTC7Protocol.java:754)
>>        - locked <0x4dda5560> (a oracle.jdbc.ttc7.TTC7Protocol)
>>        at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteDescribe(TTC7Protocol.java:860)
>>        - locked <0x4dda5560> (a oracle.jdbc.ttc7.TTC7Protocol)
>>        at
>>oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java:2391)
>>        at
>>oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2672)
>>        at oracle.jdbc.driver.OracleStatement.executeQuery(OracleStatement.java:572)
>>        - locked <0x44f61438> (a oracle.jdbc.driver.OracleStatement)
>>        - locked <0x4e07b950> (a oracle.jdbc.driver.OracleConnection)
>>        at
>>org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:188)
>>        at
>>org.apache.commons.dbcp.PoolableConnectionFactory.validateConnection(PoolableConnectionFactory.java:338)
>>        - locked <0x45b85a98> (a org.apache.commons.dbcp.PoolableConnectionFactory)
>>        at
>>org.apache.commons.dbcp.PoolableConnectionFactory.validateObject(PoolableConnectionFactory.java:318)
>>        - locked <0x45b85a98> (a org.apache.commons.dbcp.PoolableConnectionFactory)
>>        at
>>org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:833)
>>----------------
>>
>>Thanks,
>>
>>Brad Johnson
>>Texas Tech University
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: JDBC AbandonedObjectPool and PoolableConnectionFactory

Posted by John McNally <jm...@collab.net>.
yes that looks like a correct observation.  The synchronization scope
could be reduced.
john mcnally

On Wed, 2003-09-24 at 14:47, Brad Johnson wrote:
> Hello,
> 
> I noticed the latest commit to AbandonedObjectPool.java in the Jakarta Commons DBCP project. The changes seem to fix some thread blocking that I have observed lately on our Tomcat uPortal app.
> 
> I tried out the new nightly (9/24/03) today, and I think another point of thread contention has been exposed when using the validate connection features of DBCP. I'm worried that if the validation query takes too long/hangs then all the other threads that want a connection will be blocked until it times out. Do you think I'm on the right track?
> 
> "Thread-43" daemon prio=1 tid=0x0x85215f8 nid=0x29be waiting for monitor entry
> 	[5b80b000..5b80c840]
>         at org.apache.commons.dbcp.PoolableConnectionFactory.validateObject(PoolableConnectionFactory.java:316)
>         - waiting to lock <0x45b85a98> (a org.apache.commons.dbcp.PoolableConnectionFactory)
>         at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:833)
> 
> --- several threads like the above wait on the following to complete:
> 
> "Thread-98" daemon prio=1 tid=0x0x8691b10 nid=0x2a1d runnable [5c4ff000..5c501840]
>         at java.net.SocketInputStream.socketRead0(Native Method)
>         at java.net.SocketInputStream.read(SocketInputStream.java:129)
>         at oracle.net.ns.Packet.receive(Unknown Source)
>         at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)
>         at oracle.net.ns.NetInputStream.read(Unknown Source)
>         at oracle.net.ns.NetInputStream.read(Unknown Source)
>         at oracle.net.ns.NetInputStream.read(Unknown Source)
>         at oracle.jdbc.ttc7.MAREngine.unmarshalUB1(MAREngine.java:931)
>         at oracle.jdbc.ttc7.MAREngine.unmarshalSB1(MAREngine.java:893)
>         at oracle.jdbc.ttc7.v8Odscrarr.receive(v8Odscrarr.java:178)
>         at oracle.jdbc.ttc7.TTC7Protocol.describe(TTC7Protocol.java:754)
>         - locked <0x4dda5560> (a oracle.jdbc.ttc7.TTC7Protocol)
>         at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteDescribe(TTC7Protocol.java:860)
>         - locked <0x4dda5560> (a oracle.jdbc.ttc7.TTC7Protocol)
>         at
> oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java:2391)
>         at
> oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2672)
>         at oracle.jdbc.driver.OracleStatement.executeQuery(OracleStatement.java:572)
>         - locked <0x44f61438> (a oracle.jdbc.driver.OracleStatement)
>         - locked <0x4e07b950> (a oracle.jdbc.driver.OracleConnection)
>         at
> org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:188)
>         at
> org.apache.commons.dbcp.PoolableConnectionFactory.validateConnection(PoolableConnectionFactory.java:338)
>         - locked <0x45b85a98> (a org.apache.commons.dbcp.PoolableConnectionFactory)
>         at
> org.apache.commons.dbcp.PoolableConnectionFactory.validateObject(PoolableConnectionFactory.java:318)
>         - locked <0x45b85a98> (a org.apache.commons.dbcp.PoolableConnectionFactory)
>         at
> org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:833)
> ----------------
> 
> Thanks,
> 
> Brad Johnson
> Texas Tech University
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: JDBC AbandonedObjectPool and PoolableConnectionFactory

Posted by Dirk Verbeeck <di...@pandora.be>.
You can remove the synchronization of the validateObject method in 
PoolableConnectionFactory but be carefull.
If the query is slow because the database is overloaded then allowing 
more validationQueries will increase the problem.

For the next release I'm thinking about monitoring SQLExceptions thrown 
by the connection and invalidating the connection before it is returned 
to the pool.
This will cover "broken" connections. Combined with a 
"testOnBorrowOldConnection" it can replace the current "testOnBorrow".

Dirk

Brad Johnson wrote:

>Hello,
>
>I noticed the latest commit to AbandonedObjectPool.java in the Jakarta Commons DBCP project. The changes seem to fix some thread blocking that I have observed lately on our Tomcat uPortal app.
>
>I tried out the new nightly (9/24/03) today, and I think another point of thread contention has been exposed when using the validate connection features of DBCP. I'm worried that if the validation query takes too long/hangs then all the other threads that want a connection will be blocked until it times out. Do you think I'm on the right track?
>
<stacktrace removed>

>----------------
>
>Thanks,
>
>Brad Johnson
>Texas Tech University
>  
>

Re: JDBC AbandonedObjectPool and PoolableConnectionFactory

Posted by John McNally <jm...@collab.net>.
yes that looks like a correct observation.  The synchronization scope
could be reduced.
john mcnally

On Wed, 2003-09-24 at 14:47, Brad Johnson wrote:
> Hello,
> 
> I noticed the latest commit to AbandonedObjectPool.java in the Jakarta Commons DBCP project. The changes seem to fix some thread blocking that I have observed lately on our Tomcat uPortal app.
> 
> I tried out the new nightly (9/24/03) today, and I think another point of thread contention has been exposed when using the validate connection features of DBCP. I'm worried that if the validation query takes too long/hangs then all the other threads that want a connection will be blocked until it times out. Do you think I'm on the right track?
> 
> "Thread-43" daemon prio=1 tid=0x0x85215f8 nid=0x29be waiting for monitor entry
> 	[5b80b000..5b80c840]
>         at org.apache.commons.dbcp.PoolableConnectionFactory.validateObject(PoolableConnectionFactory.java:316)
>         - waiting to lock <0x45b85a98> (a org.apache.commons.dbcp.PoolableConnectionFactory)
>         at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:833)
> 
> --- several threads like the above wait on the following to complete:
> 
> "Thread-98" daemon prio=1 tid=0x0x8691b10 nid=0x2a1d runnable [5c4ff000..5c501840]
>         at java.net.SocketInputStream.socketRead0(Native Method)
>         at java.net.SocketInputStream.read(SocketInputStream.java:129)
>         at oracle.net.ns.Packet.receive(Unknown Source)
>         at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)
>         at oracle.net.ns.NetInputStream.read(Unknown Source)
>         at oracle.net.ns.NetInputStream.read(Unknown Source)
>         at oracle.net.ns.NetInputStream.read(Unknown Source)
>         at oracle.jdbc.ttc7.MAREngine.unmarshalUB1(MAREngine.java:931)
>         at oracle.jdbc.ttc7.MAREngine.unmarshalSB1(MAREngine.java:893)
>         at oracle.jdbc.ttc7.v8Odscrarr.receive(v8Odscrarr.java:178)
>         at oracle.jdbc.ttc7.TTC7Protocol.describe(TTC7Protocol.java:754)
>         - locked <0x4dda5560> (a oracle.jdbc.ttc7.TTC7Protocol)
>         at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteDescribe(TTC7Protocol.java:860)
>         - locked <0x4dda5560> (a oracle.jdbc.ttc7.TTC7Protocol)
>         at
> oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java:2391)
>         at
> oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2672)
>         at oracle.jdbc.driver.OracleStatement.executeQuery(OracleStatement.java:572)
>         - locked <0x44f61438> (a oracle.jdbc.driver.OracleStatement)
>         - locked <0x4e07b950> (a oracle.jdbc.driver.OracleConnection)
>         at
> org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:188)
>         at
> org.apache.commons.dbcp.PoolableConnectionFactory.validateConnection(PoolableConnectionFactory.java:338)
>         - locked <0x45b85a98> (a org.apache.commons.dbcp.PoolableConnectionFactory)
>         at
> org.apache.commons.dbcp.PoolableConnectionFactory.validateObject(PoolableConnectionFactory.java:318)
>         - locked <0x45b85a98> (a org.apache.commons.dbcp.PoolableConnectionFactory)
>         at
> org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:833)
> ----------------
> 
> Thanks,
> 
> Brad Johnson
> Texas Tech University
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org