wood burning stoves 2.0
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes lock-cookie generation? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "lock-cookie generation?" Watch "lock-cookie generation?" New topic

lock-cookie generation?

s yucel

Joined: Dec 04, 2005
Posts: 11
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.

public void unlock(long recNo, long cookie)
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

kind regards,
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11778


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.

Regards, Andrew

The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
I agree. Here's the link: http://aspose.com/file-tools
subject: lock-cookie generation?
It's not a secret anymore!