Bryan,
Are you suggesting that intention locks be used as "hints" to the engine
to block (e.g. suspend) transactions that would otherwise potentially
cause deadlocks/rollbacks?
Would this be in contrast to real locks that would force blocking
transactions with incompatible locks?
alex
Thompson, Bryan B. wrote:
>All,
>
>I've attached a diagram outlining some thoughts on an intention locking
>scheme based on [1]. 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.
>
>Thoughts?
>
>-bryan
>
>PS: Alex, can you "approve" this for the list -- it is oversize.
>
>[1] J.N. Gray, R.A. Lorie, G.R. Putzolu, I.L. Traiger.
> Granularity of Locks and Degrees of Consistency in a Shared Data
> Base.
> http://www.seas.upenn.edu/~zives/cis650/papers/granularity-locks.pdf
>
>
|