jena-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paolo Castagna <castagna.li...@googlemail.com>
Subject Re: Concurrent updates in TDB
Date Sun, 06 Feb 2011 15:37:35 GMT
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?

That's why it is useful, also, to have a way to timeout/cancel
long-running queries: https://issues.apache.org/jira/browse/JENA-29

> 
> 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
View raw message