File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Thoughts on synchronizing, implementing delete and on locking Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Thoughts on synchronizing, implementing delete and on locking" Watch "Thoughts on synchronizing, implementing delete and on locking" New topic

Thoughts on synchronizing, implementing delete and on locking

Brian Thorne

Joined: May 12, 2000
Posts: 8
I've worked on my Fly By Night assignment for a week and am almost done, but I have a few lose ends... I would like to know if the methods in the Data class should be synchronized or not after the lock and unlock methods have been implemented.
1. As I see it, the only purpose of locking on record level is the ability for the server to handle multiple modification requests, thus it can modify two unlocked records simoultanasly. But if the modify method is synchronized, this ability is lost, since only one call can execute the method at a time.
I'm opting to remove the synchronized modifier from the modify method because it's of no use, am I right?
2. I also want to know if you are required to implement delete functionallity even though delete is never used in the assignment. Delete would neeed to in fact lock all the records since the number of records will change, thus the locks Vector or Hashmap or whatever will be invalid after a delete, and must be recreated.
3. A final thought is the original Javadoc comment that was included for the unlock method in the original Data class:
* Unlock the requested record. Ignored if the caller does not
* have a current lock on the requested record.
public void unlock(int record) {
But how can you ever know if specifically the caller has a lock or not, when you just pass the record number to the method? You don't have a reference to the caller. hmmm...
Michael Ernest
High Plains Drifter

Joined: Oct 25, 2000
Posts: 7292

Hi Brian -
Congratulations on your progress with the exam! It can be a long road, but I hope you're learning something from it.
I'd like to respond to some of your thoughts:
1. The true purpose of locking on the record level is to make you demonstrate you know how to do it -- it's a test, after all. Seriously though, you can achieve a more efficient utilization of the data store, by reducing the scope of synchronization to the most granular operation that makes sense.
It seems like you've imagined a queue at modify(), after which nothing else can happen. In fact, anything else can happen concurrently -- except another modify() request. So if other connections are being processed outside of this call, they needn't wait for a modify() to complete to do their work. *Only* other modify calls have to wait. Now, in a world where nothing but modify() ever gets called, there's no benefit. Otherwise, you leave the door open for everything else, which can result in a more efficient execution of the program.
2. To really test your understanding of collections, implement delete(). This is a classic example of why you'd want to lock the whole database object, and not just a record, since proper iteration is at stake.
3. A tease hint: Would it make sense that the object that's assigned its lock would know who has it?
Good luck! It sounds to me like you're facing all the right challenges.
Michael Ernest, co-author of:

    The Complete Java 2 Certification Study Guide

    [This message has been edited by Michael Ernest (edited December 19, 2000).]

Make visible what, without you, might perhaps never have been seen.
- Robert Bresson
Brian Thorne

Joined: May 12, 2000
Posts: 8
Thanks Michael for your response...
I've come to realize that the lock/unlock procedure has more to it than I thought. Its main purpose (as I see it now) is to perform a transaction. That is:
1. Lock the record to make sure no one else can modify it.
2. Read the record to make sure you have the latest data.
3. Check if the entered number of seats can bee booked
(the new value for seats must not be less than zero)
4. If the value isn't valid, unlock the record and inform the user. (Rollback)
5. Write the record. (commit)
6. Unlock it.
Unlocking would be best to do in a finally block to ensure that even if an exception is thrown, the record will still be unlocked.
Thus, it has nothing to do with synchronizing data access. I realized this afrer reading the spec once more, I hope I'm on the right track.
As for delete. I will implement it, but is it required?
Merry Christmas everyone!

[This message has been edited by Brian Thorne (edited December 20, 2000).]
I agree. Here's the link:
subject: Thoughts on synchronizing, implementing delete and on locking
jQuery in Action, 3rd edition