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

My compliments!
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.

Just one side note her:

"--CELKO--" wrote:
> There are scheduling problems that need to be solved so that every
> session gets to use the database, the overall work flow is optimal or
> near-optimal, etc.

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.

Kind regards,
Carl

--
Carl Rosenberger
db4o - database for objects - http://www.db4o.com