[Sputnik-list] locking

[pierre pracht]

Le 6 mars 08 à 11:01, Jim Whitehead II a écrit :
>>>
>> No both must be saved, if needed caller must verify last available
>> version (if it's saved one).
>
> Why should both versions be saved immediately?  This is inconsistent
> with any concurrent editing application I've ever come across, and I
> fail to see the motivation behind it.

Not necessarily, this is a trade-off :
  - You sure that your data is saved, but you might be warned that's  
not the up-to-date version.
  - You never have locking problem

Last point is important : How many time a user have been caught by a  
lock in his works.
I'm sure that document lock have generated more duplicated work (make  
a copy) than they have saved.
When it isn't the case, that's due to infrequent update so less  
locking, so if no lock : few conflict.

>> 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.
>
> You're confusing the implementation of the API and the implementation
> of the storage layer.

You right I was talking about implementation of storage layer.

> What needs to be decided is what the user
> experience should look like,

You right, my point is just that we overdue synchronization problem.
User can understand that an action is done in the same time by an  
other user.
Synchronicity is a developer problem. It was important when storage  
was limited in space. Now we can handle this by keeping several copy  
of data.

How work a wiki : it keep old revisions.
Same can be done for many application.

> what the API to accommodate that is
> required, and then leave it up to the storage implementations to
> implement it.

You right, that just I didn't see the same requirement.
I think that your forum is interesting as it cross boundary :
  - entities who exists and change (id)
  - or resource (uri) who return a document (version)

>  That's the conversation I'm trying to start.
>
>>> 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)
>
> Why?

To keep storage simple and very fast.
Better it could be distributed.

- pierre