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
