Issue 576: Purpose of related LockSet (concurrency) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: In the specification, "Related lock sets" appears only in "create_related()" and create_transaction_related()" Where do I use these methods Resolution: Revised Text: Actions taken: May 20, 1997: received issue Discussion: End of Annotations:===== Return-Path: From: KENJI.KUSHI@soft23.soft.soft.hitachi.co.jp Message-Type: Multiple Part Subject: CosConcurrency questions To: concurrency@omg.org Sender: KENJI.KUSHI@soft23.soft.soft.hitachi.co.jp Date: Tue, 20 May 97 18:26:02 +0900 Content-Identifier: X Priority: normal Importance: normal X400-Received: by /C=JP/ADMD=HITNET/PRMD=HITACHI/; deferred until Tue, 20 May 97 18:26:02 +0900; Relayed; Tue, 20 May 97 18:26:02 +0900 X400-Mts-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;SOFT23970520183434CZU] X400-Originator: KENJI.KUSHI@soft23.soft.soft.hitachi.co.jp X400-Recipients: concurrency@omg.org X400-Content-Type: (22) Regarding the CosConcurrency specification(Feb 12 97), I have three questions. 1. Purpose of "related LockSet" In the specification, "Related lock sets" appears only in "create_related()" and "create_transaction_related()". At section 7.5.5 : ---------------------------- create_related Creates a new lock set that is related to an existing lock set. Related lock sets drop their locks together. create_transactional_related Creates a new transactional lock set that is related to an existing lock set. Related lock sets drop their locks together. ---------------------------- I can not understand where to use these methods. - What is the benefit of creating "related locksets" ? - What does "their locks" mean? I would like to have an actual operation with corresponding examples to drop their locks. Return-Path: From: KENJI.KUSHI@soft23.soft.soft.hitachi.co.jp Message-Type: Multiple Part Subject: Re: CosConcurrency questions To: concurrency@omg.org Sender: KENJI.KUSHI@soft23.soft.soft.hitachi.co.jp Date: Thu, 22 May 97 21:28:45 +0900 Content-Identifier: X Priority: normal Importance: normal Sensitivity: Personal X400-Received: by /C=JP/ADMD=HITNET/PRMD=HITACHI/; deferred until Thu, 22 May 97 21:28:45 +0900; Relayed; Thu, 22 May 97 21:28:45 +0900 X400-Mts-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;SOFT23970522213740DQ3] X400-Originator: KENJI.KUSHI@soft23.soft.soft.hitachi.co.jp X400-Recipients: concurrency@omg.org X400-Content-Type: (22) Thank you for response. Your responses are very helpful. This is my last question for now. My understanding of your response is that,"related" is very simple conscept. Their related locks are droped at a time. If a LockSet A has one read locks and two upgrade lock and other LockSet B which is related with A has two upgrade locks, the unlock( "read" ) operation of A may causes dropping five locks. Below is a pseudo code of this situation. { LockSet A=LockSetFactory::create(); LockSet B=LockSetFactory::create_related(A); : A->lock("read"); A->lock("upgrade"); A->lock("upgrade"); : B->lock("upgrade"); B->lock("upgrade"); : A->unlock("read"); // dropping all locks : } If I am wrong, correct me. I think there are a strange outcome if related LockSets have locks which are associated with many transactions. For example using above LockSet A and LockSet B, If locks of LockSet A associated with a transaction A and locks of LockSet B associated with other transaction B are related, the completion of transaction A may drop locks associated with transaction B which should be droped at the end of transaction B. Below is a pseudo code of this situation. I cannot find a application which requires this situation. Please teach me a typical sample using related locks. Transaction A Transaction B { { : : LockSet A= : LockSetFactory::create(); : : LockSet B= : LockSetFactory::create_related(A); : : CosTransaction::begin(); CosTransaction::begin(); : : A->lock("read"); : : B->lock("read"); : : CosTransaction::commit(); : : // dropping both locks : : : : : : CosTransaction::commit(); } // no locks ? Thanks in advance. Regards, Kenji Kushi. > >>I don't believe so because the LockFactory has both methods >>create_transaction_related() and crete_related(). >>However, I don't know how to drop related locks. >>The specification has two methods for dropping locks. >>LockCoordinator::drop_locks() and LockSet::unlock(). >>Which operation drops their related locks together? >>Please provide me a typical sample code using related locks. > > LockSet::unlock(mode) drops a single lock of the specified mode for that > lock set. LockCoordinator::drop_locks() drops all locks controlled by > that lock coordinator. Related lock sets share a single lock coordinator > or have multiple lock coordinators but synchronize their action so locks > are dropped together. > Return-Path: From: KENJI.KUSHI@soft23.soft.soft.hitachi.co.jp Message-Type: Multiple Part To: concurrency@omg.org Sender: KENJI.KUSHI@soft23.soft.soft.hitachi.co.jp Date: Fri, 23 May 97 15:52:45 +0900 Content-Identifier: X Priority: normal Importance: normal Sensitivity: Personal Subject: Re:Re: CosConcurrency questions X400-Received: by /C=JP/ADMD=HITNET/PRMD=HITACHI/; deferred until Fri, 23 May 97 15:52:45 +0900; Relayed; Fri, 23 May 97 15:52:45 +0900 X400-Mts-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;SOFT23970523160129CVE] X400-Originator: KENJI.KUSHI@soft23.soft.soft.hitachi.co.jp X400-Recipients: concurrency@omg.org X400-Content-Type: (22) Dear Thomas. Thank you for response. Your responses are very helpful. Best Regards, --Kenji Kushi >>My understanding of your response is that,"related" is very simple conscept. >>Their related locks are droped at a time. >>If a LockSet A has one read locks and two upgrade lock and other LockSet B >>which is related with A has two upgrade locks, >>the unlock( "read" ) operation of A may causes dropping five locks. >>Below is a pseudo code of this situation. > > No, unlock(mode) drops a single lock. LockCoordinator::drop_locks() drops > all related locks. > >>{ >>LockSet A=LockSetFactory::create(); >>LockSet B=LockSetFactory::create_related(A); >> : >>A->lock("read"); >>A->lock("upgrade"); >>A->lock("upgrade"); >> : >>B->lock("upgrade"); >>B->lock("upgrade"); >> : >>A->unlock("read"); // dropping all locks > > Not really, just drop a read lock of A. > > ? >>I think there are a strange outcome if related LockSets have locks which are >>associated with many transactions. >>For example using above LockSet A and LockSet B, >>If locks of LockSet A associated with a transaction A >>and locks of LockSet B associated with other transaction B are related, >>the completion of transaction A may drop locks associated with transaction B >>which should be droped at the end of transaction B. > > Related locks are mostly used in context outside of a transaction. The > case you mentioned is a pretty strange one. I guess an implementation may > either allow the calls, but show strange behavior, or raise some exceptions > on your requests. Obviously locks on different transactions should not be > declared as 'related'. > >>Transaction A Transaction B >>{ { >> : : >>LockSet A= : >> LockSetFactory::create(); : >> : LockSet B= >> : LockSetFactory::create_related(A); >> : : >>CosTransaction::begin(); CosTransaction::begin(); >> : : >>A->lock("read"); : >> : B->lock("read"); >> : : >>CosTransaction::commit(); : >> : // dropping both locks : >> : : >> : : >> : CosTransaction::commit(); >>} // no locks ? > > One simple error, you need to create the transaction, then followed by > the lockset object. Otherwise the lockset is considered non-transactional. > > Related lock is not a significant feature within a transaction. Locks > inside a transaction are already released as a group upon commit or rollback. > > { > LockSet A = LockSetFactory::create(); > A->lock(lock_mode::read); > LockSet B = LockSetFactory::create_related(A); > B->lock(lock_mode::write); > LockCoordinator coord = A->get_coordinator(CORBA::NIL /* not in trans */ ); > coord->drop_locks(); // drop locks of A and B > } > >>Kenji Kushi. >