Re: Q about overlapping transactions...

Hi Steve,

I got a meaningful response from Jan! (Thanks Jan...) Jan points out simultaneous release of locks prevents the problem I mentioned so my question becomes: Has Incremental Lock Release actually ever been used in a database system? I imagine it has because it leads to better transaction concurrency. But that begs the question of how dependencies (at an application level) between data items, can be expressed adequately such that the likes of an SQL query is able to be automatically serialized.

Two data items are logically linked. They must be changed together or not at all. Between one being updated and then the other in a transaction, the pair should not be read by another transaction as their values are not yet consistent. An incremental lock scheme might consider early release of the lock on the first updated item allowing other transactions to see the result. What is there in an Incremental Lock Release based system that prevents this early release, waiting instead until both locks on the two items are available before releasing them (irrespective of the whether it is the end of the transaction)? How are such dependencies made apparent to it?

Hope that's clearer! (being understood by humans is not my strong point :(

Thanks,
Chris

without having
Steve Long wrote:
>
> chris,
>
> i am uncertain of the precise relationship you are trying to describe
> between T1, T2, and the tuples being operated on. if you can restate what
> it is you are trying to do with more clarity, perhaps you will get a
> meaningful response.
>
> hth
Received on Wed Aug 29 2001 - 22:35:46 CEST