[Maas-devel] Running with serializable isolation.

[Christian Robottom Reis]

Thanks for the considered response and analysis. The wiki example I gave
is a very simplistic conflict resultion mechanism, but there is at least
one other that might be worth investigating that I've worked with in the
past.

Bugzilla has an infamous "mid-air collision" feature which IIRC uses
tokens (timestamps in reality) to decide whether a transaction has stale
data:

    https://wiki.mozilla.org/Bugzilla:FAQ#Does_Bugzilla_provide_record_locking_when_there_is_simultaneous_access_to_the_same_bug.3F_Does_the_second_person_get_a_notice_that_the_bug_is_in_use_or_how_are_they_notified.3F
    https://wiki.mozilla.org/Bugzilla:REST_API:Methods#Update_bug_.28.2Fbug.2F.3Cid.3E_PUT.29

This feature only covers simple changes to the bug form, and the code to
handle it is quite complicated, but it does at least show you what
diverged, and allows you to fix data manually or choose to just preserve
a comment you may have made.

Bugzilla uses the REPEATABLE READ isolation level.

Other bugtrackers have similar feature requests:

    http://www.redmine.org/issues/8691
    http://trac-hacks.org/ticket/5402

Bugtrackers are different from MAAS in that most of the work is done on
an object which is updated by multiple users; in MAAS most actions are
done by a specific user. However, being a web application and the
possibility of multiple users sharing credentials, still suffer (to a
lesser degree) of the same problems. Note also:

On Thu, Oct 23, 2014 at 12:08:36AM +0100, Gavin Panella wrote:
> (b) In step 3, submit a token that uniquely defines the "version" of the
>     data upon which the changes are based, a last-modified timestamp for
>     example. If that version is no longer present in the database,
>     reject the change.

In principle this is a better alternative than clobbering concurrent
changes. I don't believe we will have enough of these that justifies in
the short term the complexity of conflict resolution.

> Even though it doesn't fix everything, I think switching to SERIALIZABLE
> with a blanket retry strategy remains worthwhile. I don't think retrying
> transactions puts us in a worse position: for any set of changes that go
> through on a retry, those changes would have (probably? certainly?) gone
> in without a retry under READ COMMITTED.

My question is what SERIALIZABLE with blanket-retry would do to the use
cases I presented in my previous email. I believe it will cause some
form of dataloss, and if so, we should consider our options carefully.
-- 
Christian Robottom Reis   | [+1] 612 888 4935    | http://launchpad.net/~kiko
Canonical VP Hyperscale   | [+55 16] 9 9112 6430 | http://async.com.br/~kiko