Re: Q about overlapping transactions...

the situation is addressed in oracle by what they call a "read consistent view", which means if a data item is locked for update (start transaction) and another process requests the values (read), the second process will see the old values (pre-updated). this is at least the default behavior. oracle provides mechanisms via APIs to further manipulate this behavior, such as preventing a read during update (please wait).

"Chris Quinn" <cq_at_htec.demon.co.uk> wrote in message news:3B8D5222.6FCEAE0A_at_htec.demon.co.uk...
> 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 - 23:21:01 CEST