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

> My compliments!

Thank you very much!

> I really liked the original article, especially the consideration
> that there may be micro- and macro- views on the data. It would
> be possible to allow different concurrency strategies for different
> types of clients:
>
> (1) Client 1 could have a macro view, to do an overall calculation
> over the number of flights booked in a certain time period. He would
> not need to care about locks. What he would need would be mechanism
> to read data as it existed to a certain point in time.
>
> (2) Client 2 would need to make sure, a specific seat on the plane
> is still available, so he would need a micro view.
>

Yeah, I suppose the classic answer would be that these would be separate tables, but I'm wondering if there is not something more that could be done. Sometimes as I do SQL I wonder if I am working on making a wheelock more efficient when someone really just needs to invent the cartridge!

> Some object databases can solve this problem with object-level locking.
>
> I am thinking about a "locking-by-example" concept:
> You construct a graph of objects as an example to describe the depth
> of objects and all the child objects that are to be locked. This
> "lock all as the example" could be applied to a query result.

That is very interesting. To take it even further, we could assign terms to varying common graph operations, and we might wind up with lock by expression. Does any database implement that?

>
> Kind regards,
> Carl

Warm thanks for your time.

Todd Received on Tue May 06 2003 - 01:15:48 CEST