Hi all, I have a qn on the implementation of db lock. Suppose there is a request to lock the db and at the same time there are clients waiting to acquire lock for a record. What do I do???... wait until the waiting pool is empty? Also, do we need to have timeout in case the client is unable to acquire a lock after waiting for xxx ms? Anyone plz help and advise. Sarita
There are no great people in this world, only great challenges which ordinary people rise to meet.
Hi sarita, You do not have to do anything except that thread will also wait if the record is already locked. Though you will use synchronized keyword for threadsafety, but do test your code without synchronizing your lock method. If it handles X number of threads at a time then it is OK. Secondly, also make sure that you test unlock not with the client but with class Evader. This Evader class will invoke directly unlock(int record) method while your multiple clients are busy locking, modifying and unlocking the same record. Just, see to it that it does not freeze your code. Thank you,
Suppose there is a request to lock the db and at the same time there are clients waiting to acquire lock for a record. What do I do???... wait until the waiting pool is empty?
I just let the clients stay in the wait pool. If you wait for the pool to empty, you may never acquire a dblock. The way I see it, there are only two reasons to lock the db in the first place: 1. The server is shutting down or 2. Temporary db maintainance. For case 1 the lock manager is going to die which should result in a RemoteException on the client. For case 2, when unlock(-1) is called things go back to normal. If you are really concerned about case 1, you could write a finalize() method to release all the clients from the pool, maybe throwing an IOException in the process.
Also, do we need to have timeout in case the client is unable to acquire a lock after waiting for xxx ms?
The instructions say that if a lock is unavailable that the lock method should block and the javadoc on the lock method says: No timeouts are defined for this. So I would not worry about it. Hope this helps, Michael Morris
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Joined: Aug 12, 2002
Hello, Thanks Gurpreet and Micheal for the reply...that was fast. ok the timeout issue is resolved now... as for the db lock
Micheal worte as such: If you wait for the pool to empty, you may never acquire a dblock.
Actually what I had thot of is(but yet to implement), first have a waiting queue in lock mgr so before the wait() method is called I add the client to the waiting queue which is later removed upon acquiring the lock. Later, if a request for db lock is received, I set the flag for dbLock to true [this flag will fail further requests to acquireLock ie. lock(recNum) will throw an IOException] and wait until the waiting queue is empty. My idea of db maintenance is that it's temporary of course, but can take quite a while to complete. I would rather inform clients to try again later then to keep them waiting... Feel free to correct if am wrong or if it's a bad idea altogether. Frankly speaking, I am really confused as to how much we should consider for this assignment... certified scjds out there probably u'd like to share ur views on ... "how much is too much and how much is just enuf". Sarita
Joined: Jan 30, 2002
... first have a waiting queue in lock mgr so before the wait() method is called I add the client to the waiting queue which is later removed upon acquiring the lock.
So on a dblock you iterate thru the list of waiting clients calling notifyAll() until the list is empty? Do you throw an Excption on each client? Sounds like it will work fine and not be overly compicated. You could do the same thing in your finalize() method to take care of case 1. Michael Morris