On 04/02/11 01:01, Frank Budinsky wrote:
Paolo Castagna<[email protected]> wrote on 02/03/2011 05:24:32
PM:
[image removed]
Re: Concurrent updates in TDB
Paolo Castagna
to:
jena-users
02/03/2011 05:29 PM
Please respond to jena-users
Frank Budinsky wrote:
Hi,
In a previous exchange Damian told me:
You can't write
to the same TDB store from different processes.
I'm wondering if there are any safe exceptions? For example, is it safe
if
one process always adds/removes/updates statements in named graphs,
while
the other process works exclusively in the default graph (i.e., the
graphs
being used by the two processes are completely independent)? Is this
safe,
or am I treading on thin ice by using the same TDB store for both
processes?
Thanks,
Frank
For me (and us @ Talis) one concern is that MRSW (i.e. Multiple Readers
Single
Writer) locking necessary is a MR xor SW (i.e. exclusive or). So, a very
long
write operation can actually stop others reading until the write has
finished.
Isn't the opposite problem even worse? Won't a very long read operation
(e.g., a bad SPARQL query that runs for hours) block any updates to the
database for hours?
Does Fuseki have a way to avoid this problem?
No, not currently.
Andy
Frank.
So, if you allow big/long updates, you need to carefully consider
alternatives
to avoid this problem.
A slower(?) (than native TDB) alternative could be TDB-BDB:
https://github.com/afs/TDB-BDB
Having a systems with multiple replica helps as well.
Thinking other alternative approaches [1] is too scary for me at
this time, but
it would be good to list and describe them (just in case there are people
keen
to help on this) or share good papers to read which describe an approach
which
is compatible with TDB design.
Paolo
[1] http://en.wikipedia.org/wiki/Multiversion_concurrency_control
