Re: The C in ACID

Paul Mansour wrote:
> paul c wrote:
> > My guess is that they're saying, to turn it around a bit, that the user
> > must not be allowed to pervert the dbms purposes of A,I and D. And that
> > the user (or DBA) must tell the dbms how to test for Consistency. It's
> > true that most systems usually require the user to tell them where a
> > transaction starts and where it finishes, but that's different from
> > telling it how.
>
> No, I don't think so. Explaining "Consistency" they write:
>
> "There is no system mechanism that prevents a user from entering a bad
> transaction, e.g., crediting the wrong amount to a bank account, or
> charging for an item that was not shipped."
>
> This is clearly referring to correctness, no?
>
> I was under the impression that the terminolgy and interpretation of
> ACID was pretty much agreed on, but this paper call the 'C' Consistency
> but appear to mean "Correctness."

Interpretation of 'C' (in ACID) is indeed pretty much agreed upon. What database states are considered consistent is defined solely by consistency predicates (also known as integrity constraints), e.g balance >=0.

So, for a transaction to qualify for 'C', it should preserve consistency predicates it may affect. So, if each transaction preserves database consistency, so does any serial execution of such transactions. Since serializable execution is equivalent to some serial run, a database that implements correctly serializable execution is always consistent (with respect to consistency predicates defined by the database designer).

If the Microsoft researchers had read more carefully any concurrency control textbook, for example a book written by another MS researcher Phil Bernstein, they would probably have not caused as much confusion. Received on Mon Aug 21 2006 - 20:53:32 CEST