incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paolo Castagna (Commented) (JIRA)" <>
Subject [jira] [Commented] (JENA-161) TDB Transaction deadlock
Date Thu, 17 Nov 2011 13:44:51 GMT


Paolo Castagna commented on JENA-161:

 --> replay(Journal journal, DatasetGraphTDB dsg) 
      --> dsg.getLock().enterCriticalSection(Lock.WRITE)
      <-- dsg.getLock().leaveCriticalSection()

 --> readerStarts(Transaction txn)
      --> txn.getBaseDataset().getLock().enterCriticalSection(Lock.READ)
 --> writerStarts(Transaction txn)
      --> txn.getBaseDataset().getLock().enterCriticalSection(Lock.READ)
 --> readerFinishes(Transaction txn) 
      --> txn.getBaseDataset().getLock().leaveCriticalSection()
 --> writerCommits(Transaction txn)
      --> txn.getBaseDataset().getLock().leaveCriticalSection()
           --> JournalControl.replay(txn)
 --> writerAborts(Transaction txn)
      --> txn.getBaseDataset().getLock().leaveCriticalSection()

If I understand the problem is that by the time a reader finishes and JournalControl.replay(txn)
is called (which needs to acquire a WRITE lock) another reader came in (which acquired a READ
lock) and therefore the WRITE lock is never acquired.

Maybe, as a temporary workaround to this problem, before we "write-back using a separate thread",
we could use tryLock [1] in JournalControl.replay(...) method instead of lock (in order to
avoid deadlocks). If we want to try this a different Lock implementation needs to be provided
and used by DatasetGraphTxn.

> TDB Transaction deadlock
> ------------------------
>                 Key: JENA-161
>                 URL:
>             Project: Jena
>          Issue Type: Bug
>          Components: TDB
>    Affects Versions: TDB 0.9.0
>         Environment: Windows 7 64 bit. I am using the snapshot of SVN of 10 November
>            Reporter: Simon Helsen
>            Assignee: Andy Seaborne
>         Attachments:
> While running some tests I ran into a deadlock. Unfortunately, on my 64 bit windows 7,
I was unable to trigger the complete stack trace. (there is no equivalent of kill -3 and all
known utilities to achieve this on windows don't work with a 64 bit process). I was able to
see two of the threads which were hanging (because of a UI view in our admin console), but
it is not showing the other threads (which I'd need to see why the 2 threads I do have are
hanging). I will show the 2 threads which are hanging here in the hope it rings a bell. I
hope I will be able to get a full set of stack traces at some point
> as for an analysis: Not sure if we are dealing with a double-crossed locking issue here.
It seems that thread 2 is waiting for thread 1 who clearly has the lock on the transaction
manager, but it is not clear why it is waiting on the Transaction object. It seems that some
other thread still has it and the question is whether thread 2 could be the one (so there
is a crossing of the locks)? It would surprise me because thread 1 is doing a READ transaction
and thread 2 is doing a separate WRITE transaction. 
> thread 1:
> ------------
> com.hp.hpl.jena.tdb.transaction.Transaction.signalEnacted(
>    com.hp.hpl.jena.tdb.transaction.TransactionManager.enactTransaction(
>    com.hp.hpl.jena.tdb.transaction.TransactionManager.processDelayedReplayQueue(
>    com.hp.hpl.jena.tdb.transaction.TransactionManager$TSM_WriteBackEndTxn.readerFinishes(
>    com.hp.hpl.jena.tdb.transaction.TransactionManager.readerFinishes(
>    com.hp.hpl.jena.tdb.transaction.TransactionManager.noteTxnCommit(
>    com.hp.hpl.jena.tdb.transaction.TransactionManager.notifyCommit(
>    com.hp.hpl.jena.tdb.transaction.Transaction.commit(
>    com.hp.hpl.jena.tdb.transaction.Transaction.close(
>    com.hp.hpl.jena.tdb.DatasetGraphTxn.close(
> <snip>
> thread 2
> ------------
> com.hp.hpl.jena.tdb.transaction.TransactionManager.notifyClose(
>    com.hp.hpl.jena.tdb.transaction.Transaction.close(
>    com.hp.hpl.jena.tdb.DatasetGraphTxn.close(
> <snip>

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message