[Jdbm-developer] Re: intention locking JPEG

[Alex B. <boi...@in...>]

Bryan,

I'm still confused.  Assuming that we have a collection data-structure
that supports concurrent updates, what's the benefit of placing an
intention write lock (IX) on the collection?

alex

Thompson, Bryan B. wrote:

>Alex,
>
>Yes, that would be the purpose of an intention lock.  However it is
>not in contrast to "real" locks, but as a mechanism which can be used
>to increase concurrency through hints about the read/write set of the
>transactions.  The model supports six locking modes, including an
>exclusive lock (X) as well as a share lock (S).
>
>For example, if the application wants to model a collection of records
>and will need update access to some members of the collection, then it
>can use an IX (intention exclusive) lock request on the collection and
>issue X (exclusive) lock requests for specific records in the collection.
>
>As I see it this provides higher concurrency than the alternatives,
>which would either be to require exclusive access to the collection
>(serializing update access to the entire collection) or to attempt to
>lock the individual records without the benefit of coordination through
>the intention lock on the collection (more likely to result in deadlock
>since the intention locks are not there to help schedule the transactions
>so as to respect their declared intentions).
>
>-bryan
>
>[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
>
>-----Original Message-----
>From: Alex Boisvert
>To: Thompson, Bryan B.
>Cc: 'jdb...@li... '
>Sent: 2/21/2006 3:57 PM
>Subject: Re: intention locking JPEG
>
>
>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
>  
>
>> 
>>
>>    
>>