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
[a...@apache.org] Gesendet: Sonntag, 21. Juli 2013 15:12 An:
users@jena.apache.org Betreff: Re: transactions and multiple
threads
t: Montag, 22. Juli 2013 16:41
An: users@jena.apache.org
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()&q
led .begin.
Andy
ciao, Andreas
Von: Andy Seaborne [a...@apache.org]
Gesendet: Sonntag, 21. Juli 2013 15:12
An: users@jena.apache.org
Betreff: Re: transactions and multiple threads
On 20/07/13 11:33, Billig, Andreas wrote:
Hello team,
we have to use tdb
At one time I had a similar requirement, we did not have a requirement for
an update to be immediately available. My solution was to wrap the
model/graph layer so that all writes were written to a queue and a single
thread processed the writes. We ended up writing transaction blocks to the
queue
text.
What you mean with "It might be better if the writer thread is the one that
created the
transaction." ?
ciao, Andreas
Von: Andy Seaborne [a...@apache.org]
Gesendet: Sonntag, 21. Juli 2013 15:12
An: users@jena.apache.org
Betreff: Re: transacti
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
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. So, according to
the docu statement
(*) "Applications needing to do so must ensure that only one thread starts the
transaction, via a Dataset
