jena-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Budinsky <fra...@ca.ibm.com>
Subject Re: Concurrent updates in TDB
Date Fri, 04 Feb 2011 01:01:48 GMT


Paolo Castagna <castagna.lists@googlemail.com> 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?

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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message