Re: Improving API for lists, or wildcarded schemas



In <20040130140301 9621 50584 polymer turner gestalt entity net>, Dave Cridland [Home] wrote:

> On Thu Jan 29 21:46:25 2004, Tony Houghton wrote:
> >In <1075405273 4474 47 camel localhost localdomain>, Havoc Pennington 
> >wrote:
> >>An argument for it though is that getting, modifying, and resetting a
> >>list is current not an atomic operation, to avoid races you really need
> >>a way to make an "append to list" or "insert into list" request.
> >
> >If you can use some internal locking functions it could be implemented
> >simply by:
> >
> >lock
> >read list
> >delete/change item, or copy it for reading
> >write list if it's changed
> >lock
> 
> Or a conditional store, which seems to be the mechanism most used in 
> IETF-land:
> 
> a) Associate a generation metadatum with each value. (Hey, I've always 
> wanted to use the word "metadatum") In general, times seem very popular, 
> the trick being that you make the millisecond portion always increase with 
> every set/store operation.
> 
> b) Allow a set/store to optionally assert that the generation metadatum has 
> not changed. Typically, with times, this is done with an "unchanged since" 
> mechanism, so that clients can assert that the data is no newer than the 
> last update they received from the server, and don't have to retain the 
> generation metadata for all values.
> 
> There's (IMHO) big advantages over a lock metaphor:
> 
> 1) A badly written (or compromised) client cannot deny service to others.
> 
> 2) The server is simpler, since it needn't maintain locks.
> 
> 3) No special handling is needed for a client-crash.
> 
> 4) Clients can maintain the generation metadata across sessions.

I realise locking has the potential for one application to block others,
that's why I suggested keeping the lock internal - ie not exposed in the
API - and only using it from gconf functions.

The trouble with conditional store is that it could lead to race
conditions.

-- 
TH * http://www.realh.co.uk



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]