aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S - 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 "B&S - Locking" Watch "B&S - Locking" New topic
Author

B&S - Locking

Joshua Fix
Ranch Hand

Joined: Sep 18, 2007
Posts: 57
You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server.

This statement makes me think that the instructions are encouraging me not to code any synchronization blocks in my actual database accessor class, but instead to completely handle the issue through the lock/unlock functions provided in the interface.

Here is my design: My server spawns a new request handler thread when a socket is connected. The request handler holds a private copy of my Data object which implments DBMain. The handler unmarshals the request object, and based on the command specified, calls the corresponding interface method in the Data class. My Data class uses the Facade pattern and has 2 static member variables; one for my DatabaseAccessor class and one for my LockManager.

So regardless of how many new RequestHandler objects I create, and in turn how many new Data objects I create, since the DatabaseAccessor object is a static member of the Data class, multiple client threads CAN access the same DatabaseAccessor instance...

SO... I still want to synchronize blocks of code in my DatabaseAcecssor class, right? I currently have my Data class call lock and unlock immediately before and after updating and deleting a record, but not before creating a record because I don't have a record number to lock. So if one client is in the middle of deleting a record and another client is in the middle of creating a record, I could have some real problems if I'm not synchronizing on something.

And finally, since there may be multiple Data instances created, but DatabaseAccessor is a static member of Data, there will only ever be one instance of DatabaseAccessor... It makes sense for some of the members of DatabaseAccessor to be static, such as my index map... but if there is only ever one instance, does it matter? Even though the instructions say only one program is accessing the database file, does that mean that we shouldn't code it so that it doesn't explode if a second instance ever gets created? It seems like the right thing to do, but I feel like I'm going against the instructions by doing it.

Sorry for the long winded post!!!


SCJP 5.0
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11526
    
100

Hi Joshua

I think you are asking the same question in different ways in your 2 threads, so I am going to post this reply in both. (Thanks for taking the time to rephrase your question though).

You might want to look at the JavaRanch SCJD FAQ. In particular the section on "Can't we synchronize the update() method and ignore the lock() methods?" which is also the same as the section "Why do we have lock() methods in the Data class?"

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Sum Nejm
Greenhorn

Joined: Sep 20, 2007
Posts: 22
Also, wouldn't you agree that you should have some locking for your single resource (your file) so that you can not accidentally read data that is being written?

For example
1. Client A looks for a Contractor
2. Client A locks that Contractor for editing
3. Client A calls update and writing commences
4. Client B calls read and looks for the same Contractor
5. Client A finishes update
6. Client B may now have loaded partially stale and partially updated data
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: B&S - Locking