Basically just like Max does in his book, A static HashMap in the Data class is used to store record/lockcookie mappings for all clients. Each client holds the lockcookie while it has a lock on a record. All other clients wait until the lock holding client gives up the lock. Unlocking removes the record/lockcookie mappings from the HashMap and notifies all waiting clients.
The only difference is I syncronize on the static Hashmap object for all locking actions not using method sync, I also said I was assuming each client would only have one cookie at any one time (an iffy statement at best)
Mark:This thread will be moved to the more appropriate Certification Results forum.
But not immediately, because we now apply the rule slightly differently (we just try this): in this case, as I was the first to see it, I'll be the one who will copy it to the Cert Results forum and close it here. But I'll wait till Andrew sees it also, plus one day. So in practice, such a thread stays open here during two days on average (if a sheriff doesn't close it in the meantime, of course ).
Now if such a thread leads to an interesting design discussion, it may never close. Especially if it helps us find out where the weird 44/80 score for locking is coming from!
p.s. My guess is you went simple.
Mmh... OK, Mark. If Hugh's locking design is that simple, we won't close this one, promised!
Come on, Hugh!
Phil. [ May 31, 2004: Message edited by: Philippe Maquet ]
All records are cached as record objects (a custom class)
Lock mappings are stored in the Data attribute (all synchro is done on this oject for locking actions) private static HashMap recordsLocked = new HashMap();
As above in the Data class I implement the Sun supplied,
public long lockRecord(long recNo)throws RecordNotFoundException (if mapping already exists for this record wait until lock released, otherwise add new record/random lockcookie mapping to HashMap recordsLocked )
public void unlock(long recNo, long cookie)throws SecurityException ( check using Data method isValidRecordLock(recNo, cookie) if a record lock exists for this record/lockcookie combination, if so remove mapping from hashmap. )
These methods are wrapped in the Remote implementation, in the local implementation the methods throw new UnsupportedOperationException ("No local locking implemented");
Each clients controller class has a connetion object (local or remote Database access implementation ) and stores one lockcookie
The client only uses locking when a RMI client books a record, for a local connetion -1 passed as lockcookie indicates ignore lcoking.
Hope it helps.
ps. I found the most confusing aspect of the project was exception handling, I just passed everything up to the GUI controller, which rewrapped the message and sent it to a GUI level error display method to generate a dialog window with the original cause string. I could not see any case where I would handle an exception at a lower level. Still not sure if this is right.
Congrutalations Hugh, Great Score.. ! I was just curious about the create()/delete() methods of data class.. did you implement them, although your clients dont use them ? or did you just throw "Unsupportedexception" like some other guys did..
I was wondering if you synchronized any of your methods or only some interior parts of the methods. I am having a difficult time figuring out where I should be synchronizing.
Joined: Jul 28, 2003
I did implement fully all the Sun supplied DBAccess methods, I thought it was good practice. Just did not use them in the GUI controller, but they can be easilly used by anyone extending the code in the future,
I only used object block synchronizing, as I found it easier to get my head around the idea of locking up a particular object while a change is being made.
Joined: Oct 29, 2003
Thank you for your quick response. I will go through my methods and ensure that the critical sections are protected.
author and jackaroo