You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Simon Helsen <sh...@ca.ibm.com> on 2012/08/14 00:19:28 UTC
TDB transaction API issue or bug?
Hi everyone,
so I am trying to validate the current snapshot of 2.7.4, but I am running
into a few issues which surprise me. The first one is that in my log I
first find the following kind of warning:
17:49:37,851 [jazz.jfs.indexer.internal.triple] WARN TDB -
Transaction not active: 2
A little later, I get the following exception:
17:55:13,038 [1839623590@qtp-1078149187-20] ERROR com.ibm.team.jfs -
Originating Exception:
com.hp.hpl.jena.shared.JenaException: leaveCriticalSection: No lock held
(1839623590@qtp-1078149187-20) Thread R/W: 0/0 :: Model R/W: 0/0 (thread:
1839623590@qtp-1078149187-20)
at com.hp.hpl.jena.shared.LockMRSW.leaveCriticalSection(
LockMRSW.java:175)
at
com.hp.hpl.jena.tdb.transaction.TransactionManager$TSM_WriteBackEndTxn.readerFinishes(
TransactionManager.java:210)
at
com.hp.hpl.jena.tdb.transaction.TransactionManager.readerFinishes(
TransactionManager.java:723)
at
com.hp.hpl.jena.tdb.transaction.TransactionManager.noteTxnCommit(
TransactionManager.java:577)
at
com.hp.hpl.jena.tdb.transaction.TransactionManager.notifyCommit(
TransactionManager.java:427)
at com.hp.hpl.jena.tdb.transaction.Transaction.commit(
Transaction.java:122)
at com.hp.hpl.jena.tdb.transaction.DatasetGraphTxn.commit(
DatasetGraphTxn.java:40)
at
com.hp.hpl.jena.tdb.transaction.DatasetGraphTransaction._commit(
DatasetGraphTransaction.java:148)
at com.hp.hpl.jena.tdb.migrate.DatasetGraphTrackActive.commit(
DatasetGraphTrackActive.java:60)
at com.hp.hpl.jena.sparql.core.DatasetImpl.commit(
DatasetImpl.java:141)
at
com.ibm.team.jfs.rdf.internal.jena.tdb.JenaTxTdbProvider.storeOperation(
JenaTxTdbProvider.java:180)
....
So, looking at this, I suspect this is because I should not call commit on
a read transaction (the operation here is a read transaction) The
documentation (
http://jena.apache.org/documentation/tdb/tdb_transactions.html) however
seems to suggest this is permitted, i.e. that commit has the same effect
as end?
Anyhow, so I change my code to not use commit in read transactions, but
then I notice that I am not seeing the results of any queries. It is not
quite clear to me if this is because write transactions did not finish
(they do use commit and then end as per documentation) or whether the read
transaction is not working.
Going further, our tests at certain points need to disconnect from the
index which corresponds (more or less) to a StoreConnection.release(this.
location); which suddenly ("suddenly" means compared to 2.7.1) complains
that transactions are still open. So I debugged and I noticed that the
store claims there is still an active read transaction which is impossible
by looking at all other threads in the debugger.
my question right now is if there is some additional explanation of the
messages above and perhaps an explanation of why it possible that
transactions are considered to be open even if they are not. I don't have
a test case right now as it may be tricky to construct, but with some
additional information, I may be able to debug more from inside our
framework.
thanks
Simon
Re: TDB transaction API issue or bug?
Posted by Andy Seaborne <an...@apache.org>.
Simon,
commit (or abort) in a read transaction should be fine. It's in teh
test suite.
I can't guess a sequence that would cause what you see just from the
description except if multiple threads were involved in one transaction
- there is little locking in the transaction manager because one
transaction is supposed to be used by one thread, so no concurrency
within a transaction.
The LockMRSW is actually only protection - it isn't actively involved in
the transaction mechanism but does ensure safety for should the app also
be making non-transactional access from before the first transaction (an
obscure case IMO).
But it should be multithread safe anyway - It's
LockMRSW.leaveCriticalSection (not the transaction mechanism) that is
throwing the exception and that comes down to a Java reentrant lock.
Andy
On 13/08/12 23:19, Simon Helsen wrote:
> Hi everyone,
>
> so I am trying to validate the current snapshot of 2.7.4, but I am running
> into a few issues which surprise me. The first one is that in my log I
> first find the following kind of warning:
>
> 17:49:37,851 [jazz.jfs.indexer.internal.triple] WARN TDB -
> Transaction not active: 2
>
> A little later, I get the following exception:
>
> 17:55:13,038 [1839623590@qtp-1078149187-20] ERROR com.ibm.team.jfs -
> Originating Exception:
> com.hp.hpl.jena.shared.JenaException: leaveCriticalSection: No lock held
> (1839623590@qtp-1078149187-20) Thread R/W: 0/0 :: Model R/W: 0/0 (thread:
> 1839623590@qtp-1078149187-20)
> at com.hp.hpl.jena.shared.LockMRSW.leaveCriticalSection(
> LockMRSW.java:175)
> at
> com.hp.hpl.jena.tdb.transaction.TransactionManager$TSM_WriteBackEndTxn.readerFinishes(
> TransactionManager.java:210)
> at
> com.hp.hpl.jena.tdb.transaction.TransactionManager.readerFinishes(
> TransactionManager.java:723)
> at
> com.hp.hpl.jena.tdb.transaction.TransactionManager.noteTxnCommit(
> TransactionManager.java:577)
> at
> com.hp.hpl.jena.tdb.transaction.TransactionManager.notifyCommit(
> TransactionManager.java:427)
> at com.hp.hpl.jena.tdb.transaction.Transaction.commit(
> Transaction.java:122)
> at com.hp.hpl.jena.tdb.transaction.DatasetGraphTxn.commit(
> DatasetGraphTxn.java:40)
> at
> com.hp.hpl.jena.tdb.transaction.DatasetGraphTransaction._commit(
> DatasetGraphTransaction.java:148)
> at com.hp.hpl.jena.tdb.migrate.DatasetGraphTrackActive.commit(
> DatasetGraphTrackActive.java:60)
> at com.hp.hpl.jena.sparql.core.DatasetImpl.commit(
> DatasetImpl.java:141)
> at
> com.ibm.team.jfs.rdf.internal.jena.tdb.JenaTxTdbProvider.storeOperation(
> JenaTxTdbProvider.java:180)
> ....
>
> So, looking at this, I suspect this is because I should not call commit on
> a read transaction (the operation here is a read transaction) The
> documentation (
> http://jena.apache.org/documentation/tdb/tdb_transactions.html) however
> seems to suggest this is permitted, i.e. that commit has the same effect
> as end?
>
> Anyhow, so I change my code to not use commit in read transactions, but
> then I notice that I am not seeing the results of any queries. It is not
> quite clear to me if this is because write transactions did not finish
> (they do use commit and then end as per documentation) or whether the read
> transaction is not working.
>
> Going further, our tests at certain points need to disconnect from the
> index which corresponds (more or less) to a StoreConnection.release(this.
> location); which suddenly ("suddenly" means compared to 2.7.1) complains
> that transactions are still open. So I debugged and I noticed that the
> store claims there is still an active read transaction which is impossible
> by looking at all other threads in the debugger.
>
> my question right now is if there is some additional explanation of the
> messages above and perhaps an explanation of why it possible that
> transactions are considered to be open even if they are not. I don't have
> a test case right now as it may be tricky to construct, but with some
> additional information, I may be able to debug more from inside our
> framework.
>
> thanks
>
> Simon
>