On 1/5/06, Russ Brown <pickscrape@gmail.com> wrote:
> 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.
>
and that is the A of ACID, Atomicity
--
regards,
Jaime Casanova
(DBA: DataBase Aniquilator ;)