MongoDB Races, Locks, and Transactions
William Reade
william.reade at canonical.com
Tue Jul 3 20:44:37 UTC 2012
On Tue, 2012-07-03 at 01:13 -0300, Gustavo Niemeyer wrote:
> So, your perceptive eyes will certainly have noticed that we have not
> one, but two problems above, in case A2 or B2 never happen. That said,
> they are in fact the same problem: one or more units of a Dying
> service are still Alive. This is a trivial problem to solve with a
> corrective agent that goes around looking for inconsistencies and
> takes action on them, and is several orders of magnitude simpler to
> get right than any kind of transactioning mechanism that has to take
> account concurrency across several agents. We can easily have multiple
> of those corrective agents running concurrently, if we police
> ourselves to only do corrective actions idempotently, which the
> described problem really is by nature.
We'll need to be a little bit careful that we always set states in the
right order. That shouldn't generally be challenging; but, eg, atm,
removing N units inevitably involves N operations, none of which are
logically dependent on each other, and so we'll need to do *something*
else if we want that specific scenario -- and possibly others -- to be
reliable.
> So, there we go. In few words, rather than implementing transactions,
> we take corrective actions.
>
> Is anyone still with me? :-)
Definitely SGTM regardless.
>
>
> gustavo @ http://niemeyer.net
More information about the Juju-dev
mailing list