Peter Stirling wrote: > Normally write transactions are exclusive because of the infamous 'two > withdrawals from your bank account' example. > > When you change a value you need to be able to stop others from changing it > again when you don't expect them to.
Sure. That's the database system's job, not the application developer's. The transactions need not actually be what you call "exclusive" (which I take to mean "no two such transactions can be running at any given instant", though on SQLite the constraint is even stricter) -- they need to be what the SQL standard calls "serializable". The simplest serialization failure occurs when two concurrent transactions want to modify the same tuple at the same time. However, if two concurrent transactions modify different tuples, then they can continue in parallel and no harm is done to the database integrity. I will note that the SQL standard mentions no such thing as an exclusive transaction. (Of course, other constraints can be imposed on the system so that it fulfills higher-level integrity constraints. In Monotone's case, my guess is that the ancestor tree needs several additional checks, but they are probably implementable by using triggers or other mechanisms). -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J "El hombre nunca sabe de lo que es capaz hasta que lo intenta" (C. Dickens) _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
