[Sputnik-list] locking

[pierre pracht]

Le 6 mars 08 à 10:10, Yuri Takhteyev a écrit :

> Restarting the locking discussion into a separate thread...
>
> So, I agree that locking is important.  My suggestion is that first of
> all we treat break locking into two problems.

Yes, we should handle differently :
   - user edit concurency (saci level)
   - node update/creation (versium level)

> 1. Versium (and not saci) should should handle race conditions in
> saving.  I.e., if a revision is being _saved_ and another save request
> comes in at the same time, then the second save request should be
> denied and the caller should be informed.

No both must be saved, if needed caller must verify last available  
version (if it's saved one).

Concurrent modification of a file would be a nightmare in simple  
storage (and other). Better to avoid it at all. Why no rely on file  
creation time to order version. Never modify file and differentiate  
them by a generated uuid.

>  How concurrent writes are
> detected should be up to the implementation: the solution for
> databases would be different from the solution for file system, I am
> guessing.  Also, I can see us having some smarter implementations that
> actually do catch concurrent writes and some simpler ones that do not.

Yes look at SQLite, better to use it than rewrite it.

> Either way, sputnik and saci should both be made aware of the fact
> that an attempt to save the node can fail

No write, should never fail (at versium level)
But upper level can check that write have the desired effect (e.g. is  
last one)

> for this reason and do
> something smart about it in terms of letting the user know.

Yes and what you suggest at sputnik level, is very good.

- pierre