• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Client identifier for lock/unlock

 
Sam Wong
Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Client id has been discussed in several threads in this forum but I wanted to elaborate on it a bit further. I haven't dived into the specifics of RMI so I don't have much to say about whether it provides a mechanism to identifying sources of the remote calls. At this stage of my design, I believe I have a way to circumvent the use of client id and yet prevent any unlocking of records by anyone other than the owner of the lock. Keeping a signature of lock() and unlock() as is isn't a big factor as people have altered it and passed the assignment. The other issue is trusting the client to do the "right" way: lock->modify->read->unlock. Personally, I wouldn't trust the client to do so but I have to respect the fact that the requirements state that the client side must expose the public methods of the Data class. With this in mind, my design idea is to:
- Provide the public methods of the Data class on the client side but they are declared protected.
- Any client GUI will be in a separate package.
- Provide another class that encapsulates the sequence of events that must occur when booking a flight. The methods will be public and thus exposed to the client. Effectively, it will provide an atomic method to booking a flight.
The consequence is that a client will not be able to unlock without first attempting to lock. If the lock attempt fails because the record is already locked, then it blocks. With this approach, there would be no need to keep track of some sort of client id.
The actual classes would be a little more elegant than stated above but it provides the jist of the approach. I haven't tested this yet but I believe it will work. Why do you guys think?
Sam
[This message has been edited by Sam Wong (edited January 24, 2001).]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic