Alternatives to ACID, non-serialized concurrent transactions?
Date: 4 May 2003 20:20:34 -0700
Message-ID: <af3d9224.0305041920.e78b7e9_at_posting.google.com>
Normally when we describe transactioned systems, we do so in terms of defining a consistent database as one whose set of transactions produce one serialized history. Numerous papers, articles, conjectures have all been posited about databases with this fundamental view of databases. Techniques for keeping a database consistent range from simple locking to more elaborate time stamp versioned control to multiversion concurrency control, all of which have different offshoots for deadlock avoidance.
However, is there any theory of a database which says that a database may not actually store a single history? That is, at an enterprise level, the effects of a small department might be just a small amount of fluctuating noise, that, a certain amount of transactions in a span below T are probably not correct information even if consistent?
One example is this:
20 people are selling orders at once. Inventory is being reduced, sales are being increased, and varying accounts are being debited and credited. It is considered a success if such information is actually accurate, after all, the systems are incredibly complex. But, here's the question. Is the inventory of a company at time 2 minutes and 32 seconds really any different than the inventory of a company at 2 minutes and 33 seconds, after several orders have been taken?
At a macro level, consider the SEC filings as a macro view of such activity. But, what is it? Let's assume that it is a snapshot of various accounts for a particular time range. If have certain revenues over a quarter, then, are those revenues based on activity from 1/1 to 4/1? What exactly is 4/1? Do we pull these transactions based upon a READ COMMITTED isolation level report, therefor, missing transactions that might be retroactively posted while we are running the report?
At the macro level of a company, does the supposed precision of ACID actually matter? Given that the company, and, the universe as a whole, is an essentially parallel enterprise, does the notion of a single serialized view of the world make any sense at all?
On the flip side of the coin, what does serializability and ACID have to say about hard real time requirements? Is there any concurrency control mechanism that can be used to satisfy hard real time requirements and still be ACID? If I have ten damns, with water about to overflow, is there any flavor of locking, multiversioning, timestamping, that will guarantee to me that my database will be consistent in short enough time to see if the dams are overflowing?
If ACID is deficient for harder real time, and not necessary for macro views, but ACID is good for some zone in between, then, what sort of questions can one ask to determine if ACID is even a desirable property for a particular problem space. And, if ACID is not desirable, then, what alternatives might be so?
Thanks! Received on Mon May 05 2003 - 05:20:34 CEST