Re: The C in ACID
- From: "David Cressey" <dcressey@xxxxxxxxxxx>
- Date: Tue, 22 Aug 2006 11:32:19 GMT
"paul c" <toledobythesea@xxxxxxxx> wrote in message
news:tHnGg.434502$iF6.88677@xxxxxxxxxxx
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.
.
- References:
- The C in ACID
- From: Paul Mansour
- Re: The C in ACID
- From: paul c
- The C in ACID
- Prev by Date: Re: The C in ACID
- Next by Date: Re: Relation Schemata vs. Relation Variables
- Previous by thread: Re: The C in ACID
- Next by thread: Re: The C in ACID
- Index(es):
Relevant Pages
|
