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 16:02:30 GMT
Andy Seaborne wrote:
> 
> 
> 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.
> 

Would the "journaled file access" approach you have suggested be a 
solution for avoiding long reads forbidding/delaying writes?


>     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