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.
What you mean with "It might be better if the writer thread is the one that created the transaction." ? 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
