In msg 5075 Ralf Schlatterbeck said:
>On Mon, Apr 07, 2014 at 09:21:29AM +0000, Bernhard Reiter wrote:
> > 
> > Shouldn't REPEATABLE READ be the default then?
>
> This depends on what your goal is. For me it's worse that users
> get a serialization error (in our current web interface the
> users sees "An error has occurred") and possibly lose their
> submitted data than the occasional wrong history entry. But
> this depends on your application and what the history is used
> for.

In msg5076 Bernhard Reiter said:
> If a change-request comes in, we currently have no way to know
> on which old values the decision for the change was made.  We
> could try to introduce a way and it would allow to decline a
> change if it was not based on the latest value. Right now I
> cannot say if this is a real use case or not.

Don't we already have conflict handling in the web interface?
 
> What I also don't like is that the behaviour is different for
> the backends.  In my view a roundup-based application should
> basically behave the same on all backends.
> 
> In anyway, we certainly have to describe the behaviour in the
> documentation.

Would this be reasonable if we use serializable or repeatable
read:

  If the interface is interactive (web) based, throw the same
  error that is raised if you try to commit data that was changed
  underneath you. (0.8.0 release of - better edit conflict
  handling (sf bug 1118790)). That way the user/application can
  decide.

  If the interface is non-interactive (e.g. email) based such
  that there is no good way to have the user reconscile the
  change, retry the commit to see if it can be done (and maybe
  send a notice on the ticket that this was a conflicted change).

This should result in:

  1) no loss of data (worst case, the user has to verify and
     resubmit, or can choose to discard the update)
  2) allows a way for a human to determine the suitability of
     the change when possible.

If we want the system to be consistant across all database
backends, isn't serializable the target we should aim for?

  -- rouilj