It sounds like you have to return a long from your lock method. So what you need to do is make sure that the long value is reasonably unique (one way is via a Random number). Then you associate that long value with the record that is locked. This long is your cookie value. When the client tries to call any method that requires the lock (so update, delete, or unlock) then they must pass the same cookie value as a parameter to the method. If the cookie value you receive is not the same as the one you have associated with the lock, then you throw the exception specified (if one is specified in Sun's interface). Regards, Andrew
Thanks for that Andrew, I have the above implemented, my problem is I am unsure of how to pass the cookie back to the client from the DataAdapter methods, or even if I should pass it back. In the Data class I have implemented the lock and unlock methods, with a hashmap storing a record_number/cookie(random_long) pair for each record lock. I then want to use an adapter class to hide the locking/unlocking from the client which will call the adapter methods, but not sure if the cookie should be returned to the client and if so how. The attempt I have so far is as per the example psudo code...
I have a number of problems with the above... 1. The spec says the Data class should be the main acces point to the database file, this DataAdapter class would not even implement DBAccess as its signatures for methods requiring locks would be different (no lock cookie required as parameter). This could cause problems if I later want a factory to return an object of DBAccess type. 2. No lock is returned to the client, just held locally within a block until released in unLock(). Mainly because I am unsure how/if to return a lock to the client as the lock/method/unlock is all handled in one method. There has to be a million better ways of doing this, I just can not see them.. Regards Hugh
posted 17 years ago
added note: my design has a single Data/DataAdapter class for all clients all public methods in the data class are synchronised.
Hi Hugh, With your server side update method handling the locking, you don't need to pass the cookie back to the client. For your solution, the cookie is really redundant. It would only be if you had the remote client calling the lock method that you need to use the cookie. You may want to think about whether Sun are hinting that they expect the client to call the lock() method or not, given that the only use for the cookie is if a remote client is using it. Regards, Andrew
given that the only use for the cookie is if a remote client is using it.
Have I misinterpreted what the lock cookie is for? I had assumed that the lock cookie is a safeguard to ensure that any client code (local OR remote) has definitely called lock() before they try to call any methods to update data. Without the cookie, a programmer might forget (or ignore) the requirement to call lock() before calling update methods. Given that, the lock cookie seems to be useful in both local and remote mode, and there is no implication that the client side of the App should call lock(). In fact, I feel that the client messing around with locking and unlocking is rather messy (just a feeling, I haven't gone that far yet).
Hi Jack, You are correct - the cookie does ensure that someone has locked the record before they update it. What I was trying to say is that if your client is not calling lock() directly then from a design perspective the cookie is redundant (we still have to use it since Sun specified it, but it gains us nothing). If you could remove the cookie requirement, then Hugh's code will still work - no one can update a record without locking it since the lock is enforced on the server side. No one can unlock a record they havent locked, since they cannot call the unlock method directly. But, put the lock methods into your client code and the cookie makes sense (of a sort). Now you do have to ensure that a client has called the lock method before doing the update. If you don't have a cookie, then there is nothing to stop a client calling update without first locking the record. So then you would have to do extra work on the server side to ensure that each client can be uniquely identified. Client side locking could have uses in the future. Say if you wanted to have two contractors working on the same day (because you only want to take one day off work). Or if you are doing hotels: say you wanted to book 2 rooms in the same hotel (you don't want yourself in one hotel and your children in another hotel (or do you? )). If you could lock both records you can confirm that they are both still available before you do the bookings. If you cannot lock both records, then you could book one record only to find the second record is unavailable. (Note: this is just hypothetical: it is definately not required for the assignment). Regards, Andrew