Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Originally posted by Peter den Haan:
It probably means that you will have to modify the signature of some of the methods supplied (lock and unlock, at least). Plenty of others before you have done this, argued in their design documentation why this must be so, and passed.
- Peter
I am using lock at only one place, that is in modify().
Search for the word "connection" in this forum and you'll get more hints than a dog has fleas. No matter how filthy the dog isOriginally posted by Chiru babu:
any other approach by which i can escape this client Id, i didn't get any better approach to ensure that client who locks a record should only be allowed to unlock.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Are you saying that you lock the record within the modify() method of Data class? If so, this is a bit eccentric, to say the least.
So are you implementing the semantics for unlock() as specified in the supplied javadoc?Originally posted by Rajesh Rajesh:
I have the locking mechanism in the Data class itself(it uses a LockManager class), which does not matter about many client's identification.
Or are you using the thread as a form of client identity? Dodgy. The RMI specification explicitly gives no guarantees that subsequent method calls to one and the same object are handled by one and the same thread (even though that is how the current implementation happens to work; I should add that Max Habibi would disagree with me on this).What it knows is the thread which wants to modify, locks the record. After calling modify, the lock is removed. So it is not client Identification specific.
No. Your locking modify() method buys you nothing above and beyond the simple method synchronization that is already present in the Data class. In particular, it does not solve the problem that locking is supposed to fix --- two clients can still engage in a race condition and double-book seats.Whoever wants to call the modify() , would lock and unlock. [...] Is this approach okay?
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Or are you using the thread as a form of client identity? Dodgy.
So inside, modify() , before replacing the old values with the new, it is locking the record and after finishing replacing,unlocks.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
It is a valid design choice, and won't prevent you from passing. It may not be the most elegant design, but it works.Originally posted by Rajesh Rajesh:
1)Modifying the signature of lock to take the client ID is correct.
You can do without the Integer; all you need is a private int field and trivial implementations of equals() and hashCode()2)Necessity of having an ClientID object( a wrapper over Integer) over an Integer object.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd