incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Seaborne (Commented) (JIRA)" <>
Subject [jira] [Commented] (JENA-161) TDB Transaction deadlock
Date Wed, 16 Nov 2011 10:18:51 GMT


Andy Seaborne commented on JENA-161:

It looks like a locking problem in the TransactionManager.

Read transactions can trigger database write-activity (hence "signalEnacted" - enacting the
term used to describe the real work of writing a transactions changes to the underlying database,
moving them from the journal.  When a reader exits, if it is the last reader blocking write-back
of the journal to the database, then the reader thread does the work of flushing the journal.
 In the future, beyond first release, write-back can be done by a separate thread which will
give the reader more predictability of performance under high load.  Having the current scheme
though makes the system more deterministic (for the developers).

> 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
> 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