On Mon, Apr 14, 2014 at 03:50:00PM +0000, John Rouillard wrote:
> 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.

Yes but the conflict handling currently only compares the previous
values and refuses to update if any have changed. It currently does
*not* handle serialization errors.

> 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.
Yes, good idea.
(Patches welcome I currently don't have much time to look into this
although this is definitely high prio)

>   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.

This is not quite true, the change can overwrite a previous change via
web interface. But: This is the case anyway if the change in the
web-interface happens a *little* earlier so that both transactions don't
conflict. We currently don't have a precondition on changes via email
that looks for modifications...

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

This is a question of performance and -- on a busy tracker -- failed
transactions. afaik at least mysql does a lot of locking in case you
want serializable so I don't think this should be the default.

Note that there is another bug concerned with serialization: The session
cookies are updated in the same transaction as the normal updates. This
often fails in a busy tracker because browsers often update session
cookies simulateneously when restarting with several open pages to a
roundup tracker (!)
I've found issue2550671 but I think I remember there being an even older
issues with the same problem.

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: office@runtux.com
allmenda.com member                     email: rsc@allmenda.com