[Maas-devel] Running with serializable isolation.
Gavin Panella
gavin.panella at canonical.com
Wed Oct 22 23:08:36 UTC 2014
On the web, a user's transaction spans:
1. Load page.
2. Make changes.
3. Submit.
whereas the application actually has two transactions, at 1 and 3. If we
wanted PostgreSQL to deal with this using transaction isolation we'd
need to hold the transaction open for an indeterminate period of time
between 1 and 3. That's not going to fly.
A couple of ways to address the scenarios you mention come to mind:
(a) In step 3, submit data before and after the user's changes. From this
calculate a delta and apply it. If it doesn't apply cleanly, reject
it and tell the user why.
This would merge the unrelated changes to the same object in
scenario 1 above, and would reject one of the hostname updates in
scenario 2.
(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.
This would reject some of the concurrent changes in both scenarios 1
and 2. This seems less desirable than (a).
The first approach seems optimal, but this isn't something I've given a
lot of thought to. I'm interested to know if there's something better.
Leases perhaps?
> 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.
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.
I also suspect most web applications do not address problems with
conflicting updates, and so MAAS is not alone. But being ahead of the
pack on this would be another way to make MAAS be and feel more solid.
More information about the Maas-devel
mailing list