[Maas-devel] Running with serializable isolation.
Christian Robottom Reis
kiko at canonical.com
Wed Oct 22 19:09:15 UTC 2014
On Mon, Oct 20, 2014 at 11:34:56PM +0100, Gavin Panella wrote:
> The first WIP proposal [1] builds up a retry helper for serialization
> failures and integrates it into the `transactional` decorator.
I'd like to discuss wider the image of retrying as a global strategy for
dealing with serialization failures. I'll use a wiki edit as an analogy
to start with.
When a wiki edit conflicts, we do not automatically reset and retry
edits. The reason is that the correct resolution is normally to merge
changes; if you just clobbered one change with another, you end up
losing information or at least not allowing the opportunity to consider
what caused the conflicts.
In the MAAS case, here are two contrived examples:
1. If we have two admins working together, one could be updating
hostnames while the other setting up new credentials. In this
case, I would expect the serialization failure to not be naïvely
retried, but instead for the changes to be merged and then
committed, possibly with user confirmation.
2. If we have two admins working together, if both load pages at the
same time and one changes a hostname to X and the other changes
it to Y simultaneously, I would expect one of the transactions to
fail with stale data.
Can anyone come up with other examples where retrying might be harmful?
I realize that optimistic concurrency does work for many use cases, but
for MAAS I'm not sure implementing it this way actually gets us to the
perfectly reliable system we aim for.
--
Christian Robottom Reis | [+1] 612 888 4935 | http://launchpad.net/~kiko
Canonical VP Hyperscale | [+55 16] 9 9112 6430 | http://async.com.br/~kiko
More information about the Maas-devel
mailing list