[Sputnik-list] locking

[Yuri Takhteyev]

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.

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.  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.
 Either way, sputnik and saci should both be made aware of the fact
that an attempt to save the node can fail for this reason and do
something smart about it in terms of letting the user know.

2. If the client tries to save edits to revision N but the latest
revision of the node in N+m, then we need to have a way of letting
them know.  We could either handle this at the versium level or at the
saci level.  At the versium level we could do this by adding a new
parameter to Versium:save_version to let it know what version we've
got:

   v:save_version{"Home_Page", "Hello", "Yuri", "changed to Hello",
current_rev = "000012"}

This would mean: don't save if "000012" is no longer the last revision.

3. Sputnik should have some decent handling for #1 and #2.  This will
take some thinking in terms of user-experience, but in the very least
we need good error messages.

4. Ideally we should also be preventing concurrent writes by letting
the user know that someone might be editing this node.  While there
are obviously user experience issues here to be resolved at the
sputnik level, we might want to implement such locking in Saci.  We
could try doing this at the Versium level, but this would mean
requiring each implementation to find its way to store locks.
Instead, I am thinking that it might be more parcimonious to have Saci
store locks in versium in an implementation-independent way (using
versium API).  I can imagine two possibilities here. (A) Lock a node
like Home_Page by creating another node called "_lock_Home_Page". (B)
Lock a node by appending the lock information to some special page
like "_locks".  I am leaning somewhat on (B).

What do you think?

>  > Not sure what you mean by "ideally when saving".  Minding the
>  >  "versium/saci" distinction, I would say that versium _shouldn't_ be
>  >  able to do this, but perhaps "saci" or "versium" should.  One solution
>  >  would be to create a node to keep track of the locks.  Also, whenever
>  >  saci saves a node to versium, it should probably ask it for the list
>  >  of revisions and check if revisions have been made.  Again, I want to
>  >  make things simpler for storage implementors, so I don't want them to
>  >  deal with this.  When versium is told to save the node, it should save
>  >  the node.  (The only thing that it should mind is handling race
>  >  condition in actual disk writes.)  Saci, on the other hand, should be
>  >  smarter, and keep track of the possibility that the user is saving
>  >  edits to revision 2 while revision 3 has been saved by someone else.
>
>  Indeed, and this is the crux of most of the problems I've run into.

-- 
http://sputnik.freewisdom.org/