Re: Alternatives to ACID, non-serialized concurrent transactions?

"--CELKO--" <71062.1056_at_compuserve.com> wrote in message news:c0d87ec0.0305050824.12d3cbf3_at_posting.google.com...
> >> And, if ACID is not desirable, then, what alternatives might be so?
> <<
>
> Several years ago Unisys had an internal project for what they called
> "logical concurrency control",which looked interesting, but I don't
> think it got out of the laboratory.
>
> The idea was to queue the actions against the database and see which
> ones shared data and which ones were disjoint.

That has always seemed like a sensible idea to me - kind of an obvious optimisation approach, an obvious exploitation of relational predicates. I'm sure existing RDBMSes use the idea to some extent or another, if not as a full blown concurrency control system.

I will point out however, that it seems equally obvious (to me anyway) that the existence of transactions makes the implementation of such an approach a much more difficult task. Especially when faced with transactions that the DBMS does not know the full scope of a transaction (i..e. the subset of tables/columns/row that the txn will read and/or update) at the beginning of each txn.

Maybe this is yet another example of the harm that transactions do...

BTW has anyone got a good link to info about this "logical concurrency control" ? A quick google was not too productive.

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Tue May 06 2003 - 14:42:38 CEST