cubicweb #197665 locking strategies for concurrent edition [waiting feedback]

In order to prevent concurrent users to alter simultaneously the same resource. Either pessimistic locking (reserve the resource for the 1rst user and prevent access to the 2nd user), or optimistic locking (reject the 2nd commit tentative). User(s) whose transaction has been rejected/rollbacked must be warned.
priority	important
type	enhancement
appeared in	<not specified>
done in	3.18.0
load	2.000
load left	2.000
closed by	<not specified>

from state (2)	to state	comment	date	User
in-progress	waiting feedback	in progress for 6 month. what is the status of that ?	2013/03/28 16:33	pydavid
open	in-progress		2012/09/19 14:48

2009/03/02 19:09, written by adimascio

One simple strategy is to get the last modification date on an edition form (or equivalent in a desktop interface), send it when validating the form and check if the last modification is still up to date.

Is this enough ?
2009/03/02 19:09, written by sthenault

I would take the optimistic approach, with maybe some additional warnings on form telling another user is editing the same enity.
2009/03/05 22:58, written by anon

this might be relevant : http://www.lshift.net/blog/2009/03/02/evserver-part3-simplified-etherpad-clone
2010/08/30 18:23, written by acampeas

also possibly relevant: http://www.webdav.org/specs/rfc2518.html
2012/09/20 11:29, written by acampeas

I'm very tempted to reject this.
- 2012/09/20 11:38, written by sthenault
  
  in vertue of?
- 2012/09/20 11:40, written by sthenault
  
  see https://www.cubicweb.org/patch/2490910 which implements one of the identical tickets