On Thu, 5 Jan 2006 22:25:21 +0100
Peter Eisentraut <peter_e@gmx.net> 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.
That's how I view it anyway, but from what I can see you can only get
at the 'official' definition if you pay for it.
--
Russ