- From: David Booth <david@dbooth.org>
- Date: Thu, 19 Sep 2013 20:30:49 -0400
- To: Sandro Hawke <sandro@w3.org>
- CC: Andy Seaborne <andy.seaborne@epimorphics.com>, public-ldp@w3.org
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? 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 00:31:20 UTC