Win a copy of Kubernetes in Action this week in the Cloud/Virtualization forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

lock-cookie generation?  RSS feed

Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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,
author and jackaroo
Marshal Commander
Posts: 12168
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!