Re: hsqldb deadlock

2010-10-12 Thread Robert Muir
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,  karl.wri...@nokia.com 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 

Re: hsqldb deadlock

2010-10-12 Thread Karl Wright
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 daddy...@gmail.com 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 rcm...@gmail.com 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,  karl.wri...@nokia.com 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