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.
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?"
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