Re: Sorting by app:edited & Concurrency

["Joe Gregorio" <joe@xxxxxxxxxxxxxx>]

On Nov 14, 2007 11:38 AM, Brian Smith <brian@xxxxxxxxxxxxxx> wrote:
> Joe Gregorio wrote:
> > > 1. Client POSTs entry A. Server chooses 2007-11-12T12:34[:00]Z
> > as entry A's
> > > app:edited property.
> >
> > The value of app:edited for a new entry is the time at which
> > it was created. How can an entry be created and yet not
> > appear in a collection feed?
>
> That is part of what I am asking in question (c): does the collection
> feed always need to be up-to-date, or is it allowed to lag behind?
>
> The creation of an entry is going to take some time. I agree that
> app:edited should be a timestamp as close to the end of the creation
> process as possible.
>
> In my server, when an entry is POSTed or PUT, the server writes the
> entry to disk exactly as it will be returned in responses. In
> particular, the app:edited element is written to a file, so, I need to
> know it before the file is completely written to disk. I also store the
> app:edited value in the file so that I don't have to rely on any files'
> mtime.

Ah, in case you care, this is the crux of your problem. Your
set is non-well founded[1].

That is, writing the 'app:edited' time stamp into the file,
but realizing that writing may take an indeterminate amount
of time, makes your set of entries, ordered by 'app:edited', non-well founded.

It may seem like a small thing but you just fell through a hole into
a world outside of normal set theory.

[1] http://en.wikipedia.org/wiki/Well-foundedness

   -joe

>
> My server also implements every POST, PUT, and DELETE as an atomic
> operation. An entry cannot appear in the feed until it is committed. I
> have to do a few filesystem operations in order to commit an entry. On a
> slow/busy webserver/network/filer combination, this is definitely enough
> time to notice this kind of ordering issue.
>
> I can rework my implementation to serialize all POST, PUT, and DELETE
> operations enough to ensure that timestamp generation and commits are
> not interleaved, but I'd like to avoid that if possible.
>
> Regards,
> Brian
>
>



-- 
Joe Gregorio        http://bitworking.org