Are you suggesting that intention locks be used as "hints" to the engine
to block (e.g. suspend) transactions that would otherwise potentially
Would this be in contrast to real locks that would force blocking
transactions with incompatible locks?
Thompson, Bryan B. wrote:
>I've attached a diagram outlining some thoughts on an intention locking
>scheme based on . This is notionally to support the rw synchronization
>problem as 1/2 of a combined locking + MVCC solution. The idea is that
>locking is used to "induce" a serialization ordering. The DAG support
>should allow cycles to be forced and provide incremental tools for
>identifying and breaking cycles. Allowing cycles let's transactions
>violate serializability and also let's us consider which transactions
>should be aborted, rather than just the tx whose lock request produced
>the deadlock. I've been collecting some references on fast incremental
>cycle detection for the DAG part.
>PS: Alex, can you "approve" this for the list -- it is oversize.
> J.N. Gray, R.A. Lorie, G.R. Putzolu, I.L. Traiger.
> Granularity of Locks and Degrees of Consistency in a Shared Data