On 1/5/06, Russ Brown <pickscrape@xxxxxxxxx> wrote: > On Thu, 5 Jan 2006 22:25:21 +0100 > Peter Eisentraut <peter_e@xxxxxxx> wrote: > > > Am Donnerstag, 5. Januar 2006 21:58 schrieb Scott Marlowe: > > > But it's not consistent. Imagine we do the one where we take one > > > from peter and give it to paul. If paul's account is stored in an > > > int, and is at 2147483647, and we add one, it does not increment, > > > and it does not cause an error that will force a transaction to > > > roll back. > > > > The effects of the commands on the database are not sensible with > > respect to the intent of the commands, but the state of the database > > is consistent both before and afterwards with respect to the > > integrity constraints defined within the database. That's what this > > is all about. ACID is about transaction processing, not about SQL > > data type semantics. > > > > That argument holds true when you consider two key points in a > transaction: before and after. But there is also a third: the > transaction itself. i.e. the actual changes that are being made to the > database. If you take the example given earlier about peter and paul, > yes the database it in a consistent state both before and after the > transaction. But it's *not* in a consistent state when compared with > the transaction itself. The transaction asked that a field value be > incremented, and after the transaction concluded this had not > happened, yet the transaction was committed. ACID > compliance requires that either all or none of the operations in the > transaction happen. In this case one of them does not. > and that is the A of ACID, Atomicity -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;)
