This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hi all, I am implementing lock mechanism. My interface for update, lock and unlock is as follows:
// Modifies the fields of a record. The new value for field n // appears in data[n]. Throws SecurityException // if the record is locked with a cookie other than lockCookie.
public void updateRecord(long recNo, String data, long lockCookie) throws RecordNotFoundException, SecurityException;
// Locks a record so that it can only be updated or deleted by this client. // Returned value is a cookie that must be used when the record is unlocked,updated, or deleted. If the specified record is already locked by a different client, the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked.
public long lockRecord(long recNo) throws RecordNotFoundException;
// Releases the lock on a record. Cookie must be the cookie // returned when the record was locked; otherwise throws SecurityException.
Each thread will have access to the data class and its methods. From this interface, it seems that the thread will call updateRecord method with its ThreadID as a cookie, and I assume at the beginning of this update method, lock will be called and the record will be locked according to this threadID. However, the Lock method seems to be generating this cookie and send it back? So I am a bit confused. any idea is highlyappreciated
The lock() method generates a cookie, which is sent back to the method that called lock(). The cookie value should then be stored, and when you want to call some other method where lock ownership must be verified, you will pass that stored lock cookie as a parameter.
Since you have lock cookies, you do not need to use thread-ids.
If you are using RMI then using thread ids is a bad idea, as there is no guarantee that one client will use the same thread for two method calls. In fact it is a trivial exercise to make a test application that can prove that two remote calls from one connected client can run in different threads.