Hi Philippe, Andrew and Bharat, You guys rock. Thank you for your contribution to this thread. I downloaded the assignment last week and thought that it is overwhelming. But after such wonderful sharing of ideas, I think I can do it. I am already learning a lot from your postings. I am doing Bodgitt and Scarper. I have few questions. Qn. 1. Why do I need to use "synchnized" keyword for delete and update methods. I have to use lock first anyway to get exclusive lock to the record I am updating or deleting. I know you are doing different assignments. To simplify my question - if I follow lock-update-unlock and lock-delete-unlock sequence, do I still have to define update and delete methods "synchronized" ? Qn. 2. After lot of inputs from you guys I have been able to write the lock() method. My lock method is as follows.
Since you guys are doing EarlyBird, your lock method probably don't return anything. But my lock method returns a cookie which must be unique. Now take a look at line 18 and 19. Bharat has recommended to use classref as an unique client identifier. I have replaced that with cookie. So I can treat cookie as the unique identifier for the client.
Does it look OK. Am I missing anything ? Qn 3 : For delete and update methods which requires to pass the lockCookie as a parameter, I am thinking of the following design.
Please let me know if there are any concerns in this design. [ September 25, 2003: Message edited by: Suds Pati ] [Andrew: put code between [code] and [/code] tags] [ September 25, 2003: Message edited by: Andrew Monkhouse ]
Hi Suds, As you can see, I edited your post, putting the code between [code] and [/code] tags. If you edit your original post you will see how I did that. The [code] tags ensure that the code appears in it's own block and indenting is maintained. This makes it easier to read. When you are editing a post there is a button below the edit window that will insert the [code] and [/code] tags for you. You can read up on the UBB code tags here.
Why do I need to use "synchnized" keyword for delete and update methods.
You want the calls to seek() and the subsequent file access to be treated as atomic operations. Otherwise you could seek to the position you want to do your update, another process could seek to the position it wants to read from, then you actually do your write operation, overwriting the wrong record.
Since you guys are doing EarlyBird, your lock method probably don't return anything.
It is not a case of URLyBird vs. Bodgitt & Scarper. It is all in the version numbers of the assignments. There are versions of URLyBird that use the lock cookie, and there are versions of Bodgitt & Scarper that do not use lock cookies.
So I can treat cookie as the unique identifier for the client.
This is what you should do. Why do you have a notifyAll() inside your lock() method? Regards, Andrew
Why do you have a notifyAll() inside your lock() method?[
You are right. notifyAll() statement as the last statement of the lock() method looks redundant. The reason why I had put that is because, if one client has finished its work with the synchronized block, it can notify all threads waiting to acquire lock on lockedRecords. I have removed the notifyAll() statement. I still need to confirm the lock design from you. when I use the following line
I am assuming that only one thread can acquire a lock on a records. So I am using lrecNo as key for WeakHashMap. Also I am using lCookie as the value of the WeakHashMap which is the unique client identifier who has acquired the lock for the record lrecNo. [ September 25, 2003: Message edited by: Suds Pati ]
Hi Suds, I have a question about your synchronizing the update and delete methods. Do you have single Data (The class which extends the given DBAccess interface) instance shared by all clients, or you have unique instance for each client accessing the server? Arun
SCJP (1.4), SCWCD, SCJD
posted 16 years ago
Hi Arun, I haven't thought about that design yet. But I am planning to use single instance for each client.
I am assuming that only one thread can acquire a lock on a records. So I am using lrecNo as key for WeakHashMap. Also I am using lCookie as the value of the WeakHashMap which is the unique client identifier who has acquired the lock for the record lrecNo.
Sounds reasonable. Apart from the key/value set for the WeakHashMap. I guess I should start by asking why are you using a WeakHashMap instead of any other Map? Now if the reason is the commonly stated reason, then we may have an issue with your choice of key and value. But I will leave that issue until you confirm your reason for using a WeakHashMap. Also: why do you create a new CookieGenerator each time you generate a cookie? Regards, Andrew
Hi Andrew, I have been thinking about the NotifyAll() in lock method for sometime now. Why do you think that NotifyAll() method is not required in lock() method. If you don't specify NotifyAll() in lock method, you are assuming that the client will call lock + operation + unlock sequence and when client calls unclock [which has NotifyAll() method], one of the threads waiting on the lockedRecords object will enter into the synchronized block. But does this comply with the record level locking ? So far I understood, the above design looks like database locking. Because every other thread has to wait until the first thread completes lock + operation + unlock, eventhough they want to lock a different record.
Hi Suds, As soon as your thread exits the synchronized block, or calls a method (such as wait()) which implicitly releases the mutex on the synchronized object, the JVM will allow another thread to gain the mutex on the synchronized object. There is no need for your code to explicitly tell any other thread that the mutex is available - the JVM will take care of that for you. Regards, Andrew