I noticed a slight discrepancy in the requirements given. Please note that the first requirement for locking mentions that if the record is already locked, the thread should give up CPU cycles and wait till it gains a lock. The second requirement for updating a record mentions that it should throw a SecurityException if the cookie is not same as the oneholding the lock. Such a situation would never arise. Before I update any record, I would lock it and if it is already locked by any other thread, it would wait till it gets free and once it is locked, it will update the record. So I believe passing the cookie in the update method is redundant. Am I correct in thinking like this? I feel locking and threading are my week spots so I just wanted to be sure.
// 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 lock(int recNo) throws RecordNotFoundException;
// 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 update(int recNo, String data, long lockCookie)
If I am correct, can I just pass the cookie in a dummie way since it is never gonna make any difference ? Will I be penalized for this ?
Even if you will probably use your own data package classes correctly, you should always think of OO principles. So it is better to make sure things don't really explode when someone is using your data package in a wrong way. After all, you package is isolated and doesn't depend on who is using it, right?