• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Help on lock and unlock methods design

 
Rudy Yeung
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The comments of the unlock method says "Unlock the requested record. Ignored if the caller does not have a current lock on the requested record." It implies that we need to have a client id associated with a locked record, and that client id represents the data client. Regardless of local or remote connection, the data client should be assigned a client id. In view of the client id creation, grateful if someone can answer my the following two design queries:
1) Which class should I use to manipulate the client ID creation? Should it be the data class? In other words, should I add a static variable clientID in the data class and a synchronized public method that increment and return the clientID.
2) The lock and unlock methods are supposed to be called from a different class, say for example flightData.class, that manipulates the lock, read, update, and finally unlock. How do the flightData.class pass the clientID of its data client into the lock and unlock methods? Please note that the given lock and unlock methods only have the record number as the method signature.
 
Mahidhar Panyam
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
These issues are in debate. However, getting a client id depends on whether you are using RMI or Sockets as your network approach. If you are using RMI, when you request RMI object for any service, it will span a different thread. The problem here is that RMI can "reuse" the threads. This way getting client info in RMI is somewhat critical. However if you are using sockets, I think you can get curret thread name(Thread.currentThread()) which is same as actual client thread. Hence reliably you can distinguish different clients.
-Mahidhar.P
 
Rahul Rathore
Ranch Hand
Posts: 324
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Believe me Rudy- there is a lot of discussion I have read- and the most astonishing revelation was that you can fearlessly change the signature of the lock and unlock methods- as long as your logic is correct. In fact as long as your documentation is sensible and logical, you can make far reaching changes in all the code provided to you- this is stated by those who have passed SCJD. One such person redesigned the entire Data class from the ground up, totally discarding the provided code. Particularly for the lock and unlock method, I get the impression that changes are being made by everybody in their signatures - including those who have passed SCJD with marks above 90%.
I am using RMI. I have changed the signature of the lock method to return an ID, and have changed the signature of the unlock method to accept an ID. There seems to be no other elegant way of doing it.
Your idea of having a static variable to generate unique client id's seems fine. But an id is not required for every client- it is only required only if the client intends to make a change-eg. make booking. But no id is required if the client is merely reading the database. Thus I generate and return an id (I call it lock ID) in the lock method.
 
Ihor Strutynskyj
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Rudy,
There are many different ways to track clients in RMI approach. You can use client's IP address (which will limit you to one client per IP), you can generate unique client ID using java.rmi.server.ObjID class, or you can use simple object (call it flightData or DataService) which will be a communication point between client and RMI server. This communication point will be created one per client per connection time, and will serve as unique client ID.
Regards, Ihor
 
Dave Boden
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, If you look at the specs, you will find that Sun lets you assume that the clients behave. You can be assume that each client will attempt a lock() before an unlock().
In the real world, sure, this would be dangerous. However, this is exam-land. I don't see why Sun would give you any extra credit for modifying the method signatures and keeping track of the client. It's just not in the specs!
However, I'm sure they won't dock you marks, either. So if you want to learn about locking techniques, go ahead.
Good luck either way, Dave.
 
Rudy Yeung
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the client ID has to take part of the role in locking and unlocking even though in most cases the unlock() method always come after the lock() method for a particular client. If you think carefully, this is not always the case to be true. Think of what will happen after a client lock it, but then during it crashes during the db updating or it loses the network connection without getting a chance to unlock it. The locked record will never get a chance to be locked, and all other clients will subsequently be blocked and not be able to access this record anymore.
 
Ajit Kumar
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
What happens when a client Locks a record (say record 1) and the client program crashes. The server will have record 1 still locked. Any other client who is looking for a lock on the same record ( record 1 ) will have to wait indefinitely(or till the server is restarted).
How are you guys handling this.
Or
Am i considering the functionality more than required.
Pls. offer your comments.
Thanks
 
Rudy Yeung
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What I will do is to set a timeout limit to the lock granted to a client. If the client processes the lock for more than the time limit allowed, the server will then check if the client is dead. If it is dead, then the server will force to unlock it.
Rudy
 
Ihor Strutynskyj
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rudy,
More general approach would be for server not to verify the client status and unlock the record himself, but simple do nothing. If the next request for this record comes from the same failed client (after the timeout expired) allow the request to proceed, otherwise grant the lock to whatever client will ask for it first. This technique is called 'optimistic leased locks'. Which is a compromise between pesimistic locking (strict timeout based) and optimistic locking (version based).
Regards, Ihor
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic