Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Lock Cookie Question

 
Jon Pengelly
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys,
I have been having a bit of trouble with the locking part of this assignment lately. One part that is causing a bit of stress is to do with the generation of lock cookies.
I have the contractors assignment and my lock and unlock methods do not have any parameters specified for cookie values - i.e. public void unlock(int recNum){...
I understand that it is a good to ensure that the only client able to unlock a record should be the one that locked the record in the first place.
However, I have had a bit of difficulty in thinking of a way to uniquely identify the client that is locking in the first place. Especially because my data instance is a singleton and so can't be used as the unique identifier.
I know there are a number of threads on this issue already and here is a summary of my thoughts so far:
- Using random numbers, system time or an incremented static variable doesn't really apply because my lock/unlock methods don't pass the cookie values as a return value or parameter.
- Using the thread ID is not a good solution because apparently RMI can't guarantee that the same thread will be used for a process (Is this right?)
- Using the data instance doesn't apply because I have set up the data class to be a singleton.
- Creating new lock/unlock methods that pass a cookie value and then using an incremented static variable or something like that sounds like it would work but I don't feel entirely comfortable with the idea of not being able to come up with a solution using the project's specified interface.
So, I was wondering if anyone had any thoughts on my commments so far. Maybe I should change data from being a singleton? Maybe I should change the methods and document the decision with supporting arguments?
Regards,
Jonathan
 
Ken Krebs
Ranch Hand
Posts: 451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome Jon,
Using the thread ID is not a good solution because apparently RMI can't guarantee that the same thread will be used for a process (Is this right?)

If you can get past the RMI problem by having your lock/process/unlock sequence executing locally on the server, you could bind your lock to the thread itself. In that case, there is no need for a cookie.
[ February 09, 2004: Message edited by: Ken Krebs ]
 
Jon Pengelly
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Ken.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic