On 20/07/13 11:33, Billig, Andreas wrote:
Hello team,
we have to use tdb in a setting where we cannot follow the "one
transaction per thread" idiom because the threads are not under our
control.
Hi Andreas,
For my better understanding - who/what is controlling the threads?
So, according to the docu statement
(*) "Applications needing to do so must ensure that only one thread
starts the transaction, via a Dataset object, and that all threads
are acting 'multiple reader OR single writer'"
And the thread creating with .begin the transaction has to be the one to
call .commit()/.abort()/.end()
we have one global transaction object T, which is started in only one
thread, and share T between thread t-1 to t-n. We also ensure that
only one thread t-i can be a writer. Is this enougth, i.e., have I
interpreted the docu in the right way ???
Should be - within a transaction, you can (carefully!) have multiple
threads on a MRSW policy (multiple reader or single writer). There's
some locking support in Jena to help - it's wrapping Jaav's
ReentrantReadWriteLock and you can use one of your own directly if
that's easier.
It might be better if the writer thread is the one that created the
transaction.
thanks in advance, Andreas
Andy
