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).
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)
Thanks for your patience, Andreas
By the way: jena&tdb is a very fine thing - congrats - we use it to implement
a CTS2 store.
-----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
>
>
