On 22/07/13 18:28, Billig, Andreas wrote:
Thanks, now it is clearer, I think I have mixed up "transaction" and
"transaction object" (instance of 'DatasetGraphTransaction', 1:1
relationship to the dataset object returned by
'TDBFactory.createDataset(...)', which performs thread-aware
operations by 'ThreadLocal', I assume).
Yes.
In our setting NO transaction
is distributed over >1 thread, we only share the dataset (and
therewith the 'DatasetGraphTransaction'-object) between threads. I
will have the following abstract situation:
Given: thread pool P={th-1,...,th-n}, global dataset object D
(singleton), two parallel requests r-1, r-2 (on the same JSP's) with
their (logically independent) transactions (_begin .. _end|_commit).
Process: threads th-i and th-j from P are assigned to r-1 resp. r-2,
which act on D in parallel. My assumption now: r-1, r-2 could be even
two writers. (1 writer would be sufficient in our setting)
Yes.
Only one writer is truly active at anyone time - any second one is
internally blocked until the first one finishes so the app doesn't have
to worry about that.
TDB transactions don't do multiple-truly concurrent writers, when you
must have database locks. TDB uses a write-ahead journal instead.
Given that a data model concepts do not map naturally to single "table
rows" = triples in RDF, it is quite possible mysterious lock contention
would occur, or triple-level locking needed (v expensive).
Thanks for your patience, Andreas
By the way: jena&tdb is a very fine thing - congrats - we use it to
implement a CTS2 store.
Thanks!
Andy
-----Ursprüngliche Nachricht----- Von: Andy Seaborne
[mailto:[email protected]] Gesendet: Montag, 22. Juli 2013 16:41 An:
[email protected] Betreff: Re: AW: transactions and multiple
threads
On 21/07/13 22:26, Billig, Andreas wrote:
Thanks Andy,
yes, we ensure that "the thread creating with .begin the
transaction has to be the one to call .commit()/.abort()/.end()".
Wrt. your question "who/what is controlling the threads?" It's
tomcat6. I initialize and store one global dataset (resp.
transaction object) in the servlet context which is started with
the container. Tomcat assigns a thread to each request after start
from its threadpool (I do'nt know where, I am not so familiar with
tomcat). So, I query tdb in the requested JSP after getting the
dataset object from the servlet context.
If one request == one transaction, then you don't need to do
anything: this is how Fuseki works.
When a SPARQL query comes in (one HTTP request), the code is called
by the web container (Jetty, in the standalone version) and it goes:
dataset.begin(READ) ; try { do query } finally { dataset.end() ; }
so even though it does not control thread allocation, the operation
is all on one thread and can use a transaction. Some other thread
can be doing the same thing elsewhere - or an update.
What you mean with "It might be better if the writer thread is the
one that created the transaction." ?
The key points where the thread-local variables are used are the
.begin/.commit etc etc.
Actually, looking at the code, it really is much safer to have all
operations within a transaction on the thread that called .begin.
Andy
ciao, Andreas
________________________________________ Von: Andy Seaborne
[[email protected]] Gesendet: Sonntag, 21. Juli 2013 15:12 An:
[email protected] Betreff: Re: transactions and multiple
threads
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
