Re: multiple changes to resources

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.    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 Thursday, 19 September 2013 21:54:32 UTC