threads blocked while getting connection from pool getAutoCommit

373 views
Skip to first unread message

LORDs_diakonos

unread,
Oct 8, 2010, 2:29:13 PM10/8/10
to H2 Database
We are using dbcp to configure db pooling.

I have many threads stuck like the one below. Any reason why this
would be . Seems like an odd place to be stuck. Does H2 limit the
number of connections or something?

"TP-Processor41" daemon prio=10 tid=0x00002aad4c60e000 nid=0x4e3f
waiting for monitor entry [0x0000000045c83000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.h2.command.Command.executeQuery(Command.java:130)
- waiting to lock <0x00002aaac118bd78> (a org.h2.engine.Database)
at
org.h2.jdbc.JdbcConnection.getInternalAutoCommit(JdbcConnection.java:
396)
at org.h2.jdbc.JdbcConnection.getAutoCommit(JdbcConnection.java:388)
- locked <0x00002aaac7530c48> (a org.h2.jdbc.JdbcConnection)
at
org.apache.commons.dbcp.DelegatingConnection.getAutoCommit(DelegatingConnection.java:
337)
at
org.apache.commons.dbcp.PoolableConnectionFactory.passivateObject(PoolableConnectionFactory.java:
684)
at
org.apache.commons.pool.impl.GenericObjectPool.addObjectToPool(GenericObjectPool.java:
1379)
at
org.apache.commons.pool.impl.GenericObjectPool.returnObject(GenericObjectPool.java:
1342)
at
org.apache.commons.dbcp.PoolableConnection.close(PoolableConnection.java:
90)
- locked <0x00002aaac7530b70> (a
org.apache.commons.dbcp.PoolableConnection)
at org.apache.commons.dbcp.PoolingDriver
$PoolGuardConnectionWrapper.close(PoolingDriver.java:273)
at
com.dotmarketing.cache.H2CacheLoader.closeConnection(H2CacheLoader.java:
452)
at
com.dotmarketing.cache.H2CacheLoader.doUnmarshall(H2CacheLoader.java:
401)
at
com.dotmarketing.cache.H2CacheLoader.loadAttributes(H2CacheLoader.java:
466)
at com.dotmarketing.cache.H2CacheLoader.get(H2CacheLoader.java:67)
......

Dario Fassi

unread,
Oct 8, 2010, 3:08:41 PM10/8/10
to h2-da...@googlegroups.com
Hi,
I use DBCP on my projects and don't have this problems.

What's your connection URL ?
Are you using MULTI_THREADED or MVCC mode ?

regards,
Dario


El 08/10/10 15:29, LORDs_diakonos escribi�:

Jason Tesser

unread,
Oct 8, 2010, 3:10:15 PM10/8/10
to h2-da...@googlegroups.com
lock_mode=0

Thanks,
Jason Tesser
dotCMS Lead Development Manager
1-305-858-1422

On Fri, Oct 8, 2010 at 3:08 PM, Dario Fassi <dfa...@gmail.com> wrote:
>  Hi,
> I use DBCP on my projects and don't have this problems.
>
> What's your connection URL ?
> Are you using MULTI_THREADED or MVCC mode ?
>
> regards,
> Dario
>
>

> El 08/10/10 15:29, LORDs_diakonos escribió:


>> We are using dbcp to configure db pooling.
>>
>> I have many threads stuck like the one below. Any reason why this
>> would be . Seems like an odd place to be stuck. Does H2 limit the
>> number of connections or something?
>>
>> "TP-Processor41" daemon prio=10 tid=0x00002aad4c60e000 nid=0x4e3f
>> waiting for monitor entry [0x0000000045c83000]
>>    java.lang.Thread.State: BLOCKED (on object monitor)
>>       at org.h2.command.Command.executeQuery(Command.java:130)
>

> --
> You received this message because you are subscribed to the Google Groups "H2 Database" group.
> To post to this group, send email to h2-da...@googlegroups.com.
> To unsubscribe from this group, send email to h2-database...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
>
>

Dario Fassi

unread,
Oct 8, 2010, 3:16:12 PM10/8/10
to h2-da...@googlegroups.com
HI,
For read intensive appps II use multi_theaded=1 without problems.

You really need lock_mode=0 , their use is not recommended for general use:

The value 0 means no locking (should only be used for testing; also known as READ_UNCOMMITTED). Please note that using SET LOCK_MODE 0 while at the same time using multiple connections may result in inconsistent transactions.

regards,
Dario


El 08/10/10 16:10, Jason Tesser escribió:

Thomas Mueller

unread,
Oct 12, 2010, 1:56:19 PM10/12/10
to h2-da...@googlegroups.com
Hi,

I don't know what the problem could be, but it might be related to
using lock_mode=0. It is dangerous to use it.

In future releases, getAutoCommit() will not execute a query by the
way. But I'm not sure if this will make your problem go away.

Regards,
Thomas

Reply all
Reply to author
Forward
0 new messages