On 05/03/14 17:31, Jean-Marc Vanel wrote:
Thanks for the advice ;
currently I suspect that *several* threads start a transaction, via a same
Dataset object ;
which tdb_transactions.html explicitely discourages.
Where? That's normal practice.
It does talk about sharing one transaction bewteen threads. Technically
possible but only diving into implementation classes.
You can have two transactional views (two datasets, same location) on
one thread as well but that can deadlock.
Your code snippet is not running inside another transaction is it?
This will deadlock:
dataset1.begin(ReadWrite.WRITE);
dataset2.begin(ReadWrite.WRITE);
dataset2.commit();
dataset2.end();
dataset1.commit();
dataset1.end();
because dataset1 takes the lock, and effectively, is waiting for
dataset2, but it can't proceed because its waiting on dataset1. Opps.
Nested transactions are not provided.
Can you confirm that it's OK that *several* threads start a transaction,
via a same directory TBD location but distinct Dataset objects ?
Yes - but better to have one Dataset for one location.
It's unnecessary to have multiple datasets for one location; you don't
gain anything.
Is it costly to build a Dataset object via TDBFactory.createDataset() ?
No -- No disk involved, no large scale data copying at create time.
But better to share the Dataset object. Note the mentioned use of
ThreadLocal variables internally so each thread has it's own
transactional scope per dataset object.
If I understand the PS , you have added in Subversion method getT
ransMgrState to DatasetGraphTransaction ?
Yes.
My code example showed how to get it with released TDB.
Andy
2014-05-03 12:15 GMT+02:00 Andy Seaborne <a...@apache.org>:
This might help:
// Setup:
Dataset dataset = ....
DatasetGraphTransaction dsgt =
(DatasetGraphTransaction) (dataset.asDatasetGraph()) ;
Location loc = dsgt.getLocation() ;
StoreConnection sConn = StoreConnection.make(loc) ;
// then anywhere:
System.out.println(sConn.getTransMgrState()) ;
will print some internal counters. It is a snapshot of the state at the
point of the call, not a live connection.
e.g.
Active (R=0 W=0) : Finished (R=0, WC=1, WA=0) Queue 1
Active - current transactions for this location.
WC - writer commited
WA = writer aborted
This does not work on all TDB datasets (particularly the anonymous
in-memory ones which you are not using).
Andy
PS I've just added a method to DatasetGraphTransaction to get this state
more conveniently which will work for all datasets.
On 05/03/14 09:54, Andy Seaborne wrote:
On 05/02/14 21:19, Jean-Marc Vanel wrote:
In fact, isInTransaction() returns false
( because ThreadLocal returns setInitialValue() ) ,
so there must be something broken in the TDB dataset .
isInTransaction returning true means that the current thread is in a
transaction, not that there is some other somewhere else in a
transaction on the same dataset.
TDB is single writer AND multiple reader. writers get queued on the
lock you are seeing so my best guess is that another thread has started
a write transaction and not committed or aborted it (hence the resources
style suggestion in the API documentation using finally)
Andy
2014-05-02 21:26 GMT+02:00 Andy Seaborne <a...@apache.org>:
On 02/05/14 18:48, Jean-Marc Vanel wrote:
Yes , it can be the case that another thread is accessing the dataset.
From what you write, and the doc.:
https://jena.apache.org/documentation/tdb/tdb_transactions.html
I understand that the kind of access that can be the cause of this
transaction not opening is
a write transaction not closed in another thread.
Yes - it's waiting on the writer transaction lock.
I have a suspect in my app code,
but is there a way to know at runtime the status of a dataset regarding
transactions ?
with more detail like the thread than :
public boolean isInTransaction() ;
There isn't another way but isInTransaction() is backed by a ThreadLocal
so it does tell you the state from the thread viewpoint.
Andy
2014-05-02 18:20 GMT+02:00 Andy Seaborne <a...@apache.org>:
Hi,
Do you have a complete, minimal example?
I built a test from the details below and it works so maybe it
something
related but not shown here.
The other thing to consider is whether any other thread is
accessing the
dataset.
Andy
On 02/05/14 14:15, Jean-Marc Vanel wrote:
Hi
I'm trying to delete a whole named graph.
The code:
try {
Dataset dataset = TDBFactory.createDataset(
directory.getAbsolutePath());
UpdateProcessor qexec = UpdateExecutionFactory.create(request,
GraphStoreFactory.create( dataset ) );
dataset.begin( ReadWrite.WRITE ); // frozen here !!!!!!
qexec.execute();
dataset.commit();
}
The SPARQL :
WITH <file:/home/jmv/ontologies/unspsc84-title.rdfs.n3>
DELETE { ?subject ?property ?value }
WHERE { ?subject ?property ?value }
The stack when suspending in debugger:
Daemon Thread [SwingWorker-pool-4-thread-1] (Suspended)
Unsafe.park(boolean, long) line: not available [native method]
LockSupport.park(Object) line: 186
Semaphore$FairSync(AbstractQueuedSynchronizer).
parkAndCheckInterrupt()
line: 834
Semaphore$FairSync(AbstractQueuedSynchronizer).
doAcquireSharedInterruptibly(int)
line: 994
Semaphore$FairSync(AbstractQueuedSynchronizer).
acquireSharedInterruptibly(int)
line: 1303
Semaphore.acquire() line: 317
TransactionManager.begin(ReadWrite, String) line: 306
TransactionManager.begin(ReadWrite) line: 287
StoreConnection.begin(ReadWrite) line: 103
DatasetGraphTransaction._begin(ReadWrite) line: 155
DatasetGraphTransaction(DatasetGraphTrackActive).begin(ReadWrite)
line:
42
DatasetImpl.begin(ReadWrite) line: 125
Jena:
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>apache-jena-libs</artifactId><version>2.11.1</
version>
<type>pom</type>
</dependency>
The system:
% uname -a
Linux oem-laptop 3.11.0-20-generic #34-Ubuntu SMP Tue Apr 1
20:40:25 UTC
2014 x86_64 x86_64 x86_64 GNU/Linux
% java -version
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
For more details, I'll be on IRC #jena .
