A brief conversation here with people who purportedly know hsqldb from
an earlier life shows that my experience is by no means unusual.
Hsqldb has apparently had problems of this kind since day one, and
people who have experience with it tend to only use it in
single-threaded environments.

Karl

On Tue, Oct 12, 2010 at 11:44 AM, Karl Wright <[email protected]> wrote:
> Technically, a database is supposed to throw a sqlexception of a
> specific variety if deadlock occurs, not just hang due to thread lock.
>  Indeed, if this is the way hsqldb handles deadlock it is not usable,
> because we *expect* there to be a possibility of deadlock under some
> conditions, and have coded backoff and retry when this is detected.
> Pre-locking everything under the sun is not an option because of the
> severe impact that has on performance.
>
> PostgreSQL has no problem with handling database deadlocks when they
> arise, FWIW.  Derby also handles deadlocks, but at the cost of a
> timeout expiration of a minute, which is fine if the deadlocks are
> rare.  In Derby's case, though, the deadlock occurs when you have one
> thread deleting rows based on a condition, and the second adding a
> row, and neither one of these in a transaction.  That's a pretty lame
> excuse for deadlock, seems to me.
>
> I will try MVCC - maybe that will help.
> Karl
>
>
>
> On Tue, Oct 12, 2010 at 11:33 AM, Robert Muir <[email protected]> wrote:
>> maybe the problem is indicative of a bug in LCF? I think its strange
>> that there are locking problems with Derby, too.
>>
>> That being said, maybe as a quick fix you could try SET DATABASE
>> TRANSACTION CONTROL MVCC or SET DATABASE TRANSACTION CONTROL MVLOCKS,
>> since i see you are using two phase locking:
>> http://hsqldb.org/doc/2.0/guide/sessions-chapt.html#sqlgeneral_trans_cc-sect
>>
>>
>> On Sun, Oct 10, 2010 at 9:18 AM,  <[email protected]> wrote:
>>> Does anybody have experience with hsqldb?  I'm getting a java thread 
>>> deadlock within about 10 seconds of running a job.  I want to know if 
>>> anyone has seen this before, or has used hsqldb in a massively 
>>> multithreaded environment.
>>>
>>> Found one Java-level deadlock:
>>> =============================
>>> "Thread-745":
>>>  waiting for ownable synchronizer 0x293b0b70, (a 
>>> java.util.concurrent.locks.Ree
>>> ntrantReadWriteLock$NonfairSync),
>>>  which is held by "Thread-725"
>>> "Thread-725":
>>>  waiting to lock monitor 0x04614284 (object 0x2927b550, a 
>>> org.hsqldb.persist.Lo
>>> bManager),
>>>  which is held by "Thread-732"
>>> "Thread-732":
>>>  waiting for ownable synchronizer 0x293b0b70, (a 
>>> java.util.concurrent.locks.Ree
>>> ntrantReadWriteLock$NonfairSync),
>>>  which is held by "Thread-725"
>>>
>>> Java stack information for the threads listed above:
>>> ===================================================
>>> "Thread-745":
>>>        at sun.misc.Unsafe.park(Native Method)
>>>        - parking to wait for  <0x293b0b70> (a 
>>> java.util.concurrent.locks.Reentr
>>> antReadWriteLock$NonfairSync)
>>>        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
>>>        at 
>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInt
>>> errupt(AbstractQueuedSynchronizer.java:811)
>>>        at 
>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(A
>>> bstractQueuedSynchronizer.java:842)
>>>        at 
>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Abstrac
>>> tQueuedSynchronizer.java:1178)
>>>        at 
>>> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(Reen
>>> trantReadWriteLock.java:807)
>>>        at org.hsqldb.TransactionManager2PL.beginAction(Unknown Source)
>>>        at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
>>>        at org.hsqldb.Session.executeDirectStatement(Unknown Source)
>>>        at org.hsqldb.Session.execute(Unknown Source)
>>>        - locked <0x23dc38d0> (a org.hsqldb.Session)
>>>        at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
>>>        at org.hsqldb.jdbc.JDBCStatement.execute(Unknown Source)
>>>        - locked <0x23dc6fc0> (a org.hsqldb.jdbc.JDBCStatement)
>>>        at 
>>> org.apache.manifoldcf.core.database.Database.execute(Database.java:52
>>> 6)
>>>        at 
>>> org.apache.manifoldcf.core.database.Database$ExecuteQueryThread.run(D
>>> atabase.java:381)
>>> "Thread-725":
>>>        at org.hsqldb.persist.LobManager.adjustUsageCount(Unknown Source)
>>>        - waiting to lock <0x2927b550> (a org.hsqldb.persist.LobManager)
>>>        at org.hsqldb.SessionData.adjustLobUsageCount(Unknown Source)
>>>        at org.hsqldb.TransactionManagerCommon.persistCommit(Unknown Source)
>>>        at org.hsqldb.TransactionManager2PL.commitTransaction(Unknown Source)
>>>        at org.hsqldb.Session.commit(Unknown Source)
>>>        - locked <0x23ca46f0> (a org.hsqldb.Session)
>>>        at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
>>>        at org.hsqldb.Session.execute(Unknown Source)
>>>        - locked <0x23ca46f0> (a org.hsqldb.Session)
>>>        at org.hsqldb.jdbc.JDBCPreparedStatement.fetchResult(Unknown Source)
>>>        at org.hsqldb.jdbc.JDBCPreparedStatement.executeUpdate(Unknown 
>>> Source)
>>>        - locked <0x23ca8038> (a org.hsqldb.jdbc.JDBCPreparedStatement)
>>>        at 
>>> org.apache.manifoldcf.core.database.Database.execute(Database.java:56
>>> 6)
>>>        at 
>>> org.apache.manifoldcf.core.database.Database$ExecuteQueryThread.run(D
>>> atabase.java:381)
>>> "Thread-732":
>>>        at sun.misc.Unsafe.park(Native Method)
>>>        - parking to wait for  <0x293b0b70> (a 
>>> java.util.concurrent.locks.Reentr
>>> antReadWriteLock$NonfairSync)
>>>        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
>>>        at 
>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInt
>>> errupt(AbstractQueuedSynchronizer.java:811)
>>>        at 
>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(A
>>> bstractQueuedSynchronizer.java:842)
>>>        at 
>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Abstrac
>>> tQueuedSynchronizer.java:1178)
>>>        at 
>>> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(Reen
>>> trantReadWriteLock.java:807)
>>>        at org.hsqldb.TransactionManager2PL.beginAction(Unknown Source)
>>>        at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
>>>        at org.hsqldb.persist.LobManager.createClob(Unknown Source)
>>>        - locked <0x2927b550> (a org.hsqldb.persist.LobManager)
>>>        at org.hsqldb.Session.createClob(Unknown Source)
>>>        at org.hsqldb.jdbc.JDBCPreparedStatement.performPreExecute(Unknown 
>>> Sourc
>>> e)
>>>        at org.hsqldb.jdbc.JDBCPreparedStatement.fetchResult(Unknown Source)
>>>        at org.hsqldb.jdbc.JDBCPreparedStatement.executeUpdate(Unknown 
>>> Source)
>>>        - locked <0x23d0d570> (a org.hsqldb.jdbc.JDBCPreparedStatement)
>>>        at 
>>> org.apache.manifoldcf.core.database.Database.execute(Database.java:56
>>> 6)
>>>        at 
>>> org.apache.manifoldcf.core.database.Database$ExecuteQueryThread.run(D
>>> atabase.java:381)
>>>
>>> Found 1 deadlock.
>>>
>>> Karl
>>>
>>
>

Reply via email to