jena-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <andy.seabo...@epimorphics.com>
Subject Re: Concurrent updates in TDB
Date Fri, 04 Feb 2011 10:19:00 GMT


On 04/02/11 01:01, Frank Budinsky wrote:
>
>
> 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?

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

Mime
View raw message