Re: The C in ACID

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:tHnGg.434502$iF6.88677_at_pd7tw2no...

> I prefer to think that the logical db has no concept of A, I and D. One
> might ask "how then, without recognizing A, I and D, could a dbms
> achieve them?" and I would say by expecting the users to take turns. In
> practice, it seems reasonable for the dbms to inflict an order on the
> users, ie., there may be a logic to a certain concurrency theory, but it
> is not the same logic we mean when we talk about a logical dbms.

It's not so much that the logical db has no concept of A, I, & D. It's that the logical db has no concept of concurrent updates & queries. The logical db is unpredictable is the I of ACID is not enforced. The enforcement of I is that any view of the db in the context of a transaction can be viewed as if it were "between" all the other transactions, although some of them may actually be concurrent. So, if I is guaranteed by the server, the logical db doesn't have to deal with the rest.

Note that the A is partly the application's responsibility as well. consider the following:

UPDATE LEDGER
   SET CREDIT = CREDIT + %AMOUNT
   WHERE ACCOUNT = %CREDIT_ACCOUNT;
COMMIT;
UPDATE LEDGER
   SET DEBIT = DEBIT + %AMOUNT
   WHERE ACCOUNT = %DEBIT_ACCOUNT;
COMMIT; The first commit is an application error. It permits another transaction to see the books in an unbalanced state.
Appropriate constraints can cause the first COMMIT to fail, but that not the point, here. The point is that the application programmer has to start and end transactions appropriately. Received on Tue Aug 22 2006 - 13:32:19 CEST