Locking and unlocking code i have lockManager for maintaining the locked records. the records are stored in two hashtables. viz hash1 and hash2 hash1 containing recno and clinetid and hash2 containing timeoflock and recno. lock( recno, clint id) while(hash1 has recno) wait.
add recno, clinetid to hash1 add timeoflock, recono to hash2 notifyall return.
unlock(recno, clientid) if(hash1.get(recno) == clinetid) remove recno from hash1 remove recno from hash2
---------------------------- Timer code get keys of hash2 from lockmanager while( have more keys) if(currentTime - key > someTime) some code that will remove the recNO key from hash1 and hash2 -------------------------- where someTime is some specefied time for cleaning up stale locks. like i feel it should be 1 min [ April 04, 2002: Message edited by: Siddharth Mehrotra ]
Hi Siddharth, I'm doing essentially the same thing except that I'm using a separate class, LockTimer which extends TimerTask and starts a Timer to which it registers itself, to timeout the locks. LockTimer has two methods to register and unregister locks. I also have an interface named LockTimerCallback with one method called lockTimedOut(), which is implemented by my LockManager. Hope this helps Michael Morris
hi Michael My Timer code is also in a seperate class. Thanks for the reply. this is the last stage of my coding i just have to implememnt the locking logic and Timer class. Thank you.
Hi there, How do you notify the client who owns the stale lock that his time has expired and that he should try to lock again ? A quick thinking brings me to some TimeOutException on the write method, thrown when the record number doesn't show up in the locked Collection anymore... Andrew
hi Andrew, well that was a topic on which i did give a thought. but lets think on the scenario when will a normal client will result in server having a stale lock stored in LockManager. well the most commoun scenario is when the n/w crashes or the sysytem holding the cleint goes down. In whcih the later has the most commoun chances of occuance, and in that case there is no way in which a client program even though informed in some way or the other through some callback mechanism, will be able to pop-up the message to the user. what do you say. !!!
Hi Andrew, I tend to agree with Siddharth, that if a lock has timed out that in all probability, the client has died. I thought about using a beans style messaging system to notify clients that a lock had been revoked but finally opted on checking to see if the record is still locked before allowing a modify to occur. If it is not locked, then I throw an exception that should notify the client that the transaction was not completed. Michael Morris
Originally posted by Siddharth Mehrotra: Locking and unlocking code i have lockManager for maintaining the locked records. the records are stored in two hashtables. viz hash1 and hash2 hash1 containing recno and clinetid and hash2 containing timeoflock and recno. where someTime is some specefied time for cleaning up stale locks. like i feel it should be 1 min [ April 04, 2002: Message edited by: Siddharth Mehrotra ]
I sure am glad I came across this posting . I just started my exam and I was thinking about implementing a singleton to handle record locking. I especially wanted to make it self-healing and time-expiring, as any good database software would do. I was going to implement a thread-safe collection to store record id's and a timestamp. The singleton would kick off a thread that looped through the collection and release a record after a reasonable time. This seems to be similar to the approach you have taken. I'm glad I wasn't completely off-base.
checking to see if the record is still locked before allowing a modify to occur. OK, I suppose that's sufficient enough, but there's still one question : Do you keep track of who is keeping a lock on the record you are about to modify ? Because if you don't, you'll pass your stillLocked-test when another client has achieved a lock on that very record... I hope I'm making myself clear :roll: Andrew [ April 05, 2002: Message edited by: Andrew Collins ]
Originally posted by Andrew Collins: Hi there, How do you notify the client who owns the stale lock that his time has expired and that he should try to lock again ? Andrew
Why would I do this? As I read the specs, it says that I'm not required to do dynamic updates to other clients. Have I missed something?
Hi, I've managed to find a way to solve the stale locks problem without the need for an extra collection. In my LockManager I have an inner class :
At the moment the LockManager adds a new record number to the lockedRecords Collection I call
So when TIME_UNTIL_LOCK_IS_FORCED_TO_OPEN has expired the unlock(recordNumber) method is ALLWAYS called. Note that under normal circumstances this method was allready called by the client. A second time doesn't harm, does it ? At first sight, this seems to work fine but I would like your opinions on this one. Thanx ps Jim, do not worry about this, it's beyond this exercise [ April 06, 2002: Message edited by: Andrew Collins ]
Andrew: I would create one instance of CountDownToLock thread instead of one thread instance for every locked record. This singleton instance will be instantiated by the LockManager constructor which also a singleton. Also I will create a Lock object which contains the record number and the timeout period. LockManager has a collection of locks which are added by the lock method and removed by the unlock method. CountDownThread object wakes up every arbitrary seconds and go through the collection and remove the locks which are no longer referenced by any client. As far as synchronizing this instance I would use class lock mechanism instead of instance locking since it is a Singleton.
Hi there, I'm afraid you've lost me. Applying a Singleton pattern on a Thread object, isn't that some sort of contradiction ? I'm no Thread guru but I find it hard to believe that when we use a Singleton on this CountDown Thread object the LockManager will wait the same amount of time for each and every client that achieved a lock before forcing the lock to open Can you explain this one please ? Thanks
![[Logo]](/templates/default/mobile/images/mobile-moose.gif)
