Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

lock/ unlock/ update/ delete discrepancy in URLyBird

 
Pankaja Bansal
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Everybody

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 ?

Cheers
PB
 
Eiji Seki
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maybe you get penalized maybe not.
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?
 
Eiji Seki
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wow, I forgot...
Also, you should use the data classes properly, since you don't know how it was implemented, right?
Remember, think of OO and team work. You could have created the data classes yourself... or maybe not.
[ February 18, 2006: Message edited by: Eiji Seki ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic