- From: Sandro Hawke <sandro@w3.org>
- Date: Fri, 20 Sep 2013 00:19:12 -0400
- To: David Booth <david@dbooth.org>
- CC: Andy Seaborne <andy.seaborne@epimorphics.com>, public-ldp@w3.org
On 09/19/2013 08:30 PM, David Booth wrote:
>
>
> On 09/19/2013 05:54 PM, Sandro Hawke wrote:
>> On 09/19/2013 04:39 AM, Andy Seaborne wrote:
>>>
>>>
>>> On 18/09/13 21:47, Melvin Carvalho wrote:
>>>> Hi All
>>>>
>>>> Has anyone thought about what happens when 2 or more people want to
>>>> access a resource or container at the same time.
>>>>
>>>> Could we develop a race condition here? Is there a basic strategy
>>>> (such
>>>> as in unix locking) that could be used to prevent such things.
>>>>
>>>> Has anyone considered this case at all?
>>>
>>> Does the use of etags and of If-* HTTP headers work for the uses cases
>>> you have in mind?
>>>
>>
>> While Melvin is consideraing that, a few more comments:
>>
>> I think whole-resource locking as in webdav is probably not what we want
>> in general, although I guess folks can use it if they want. I worry
>> about the extra round-trips and I worry about clients failing to unlock,
>> although of course that can be handled by a timeout. But seting a
>> reasonable timeout will be hard, I imagine. I guess very, very short
>> locks (< 1s) would be okay; client will always have to know how to retry
>> if/when their lock timed out.
>>
>> Ideally, I'd like us to be able to handle high concurrency (10+ patches
>> per second to a resource), which I think requires blind patching (aka
>> context diffs). A little concurrency can be handled by the If-*
>> headers. If you get an accidental collisions while using them, one of
>> the clients will back off and retry and it'll be fine. But as the
>> modification rate climbs, backing off becomes problematic. Once the
>> modification rate exceeds the round-trip-time for some clients, those
>> clients become completely unable to modify the resource. The solution
>> is for clients to construct patches which work even if the resource has
>> changed since they last knew its state (aka blind patching with context
>> diffs). I believe that can be done by having the client communicate to
>> the server which triples (existing and not-yet-existing) it's relying on
>> being unmodified.
>
> By sending a SPARQL WHERE clause?
>
That's certainly one way to do it, yes. So that would need a bigger
subset of SPARQL than I proposed in TurtlePatch or Eric proposed at the
meeting. How much bigger, I don't exactly know.
-- Sandro
> David
>
>> The If-* headers basically implement optimistic
>> concurrency control [1] at the per-resource granularity. What I'm
>> proposing is that we go down to per-triple granularity with OCC to
>> enable real-time interaction using LDP.
>>
>> -- Sandro
>>
>> [1] http://en.wikipedia.org/wiki/Optimistic_concurrency_control
>>
>>
>>> Andy
>>>
>>>
>>
>>
>>
>>
>>
>
Received on Friday, 20 September 2013 04:19:20 UTC