I agree, -- don't worry about it. The questions you raise would probably be valid in the context of the Architect Certification, but not this one.
I understand that this may not be required for SCJD. However, it will benefit us if we put some thoughts on it and I like this kind of thought.
Following my original post, I have already defined a LOCKED_RECORD status for each record. Now, let's stand at FBN User position. The locking mechanism probably can be implemented by slightly modifying the LockManager class -- within its lock/unlock method, we will update the record status as LOCKED_RECORD in db.db file while updating the HashMap. This may be done by:
1. Locking:
We will first check the status of that record in db.db. If the status is ACTIVE_RECORD, just mark it as LOCKED_RECORD and put the ClientID and recno in HashMap. If status is LOCKED_RECORD, check the HashMap and see if any FBN client owns the lock. If no, means this Lock is owned by other projects and we can do nothing except (maybe) waiting. In this way, FBN users compete with other DB users for the lock.
2. Unlocking:
Following the same concept of above locking, a record is checked the status first and only LOCKED_RECORD owned by the this user can unlock it, i.e. set back the status as ACTIVE_RECORD.
From the above, we can see that the changes to original LockManager are mainly to update the record status in db.db besides maintaining the HashMap. One assumption I need to stress here is that other DB users also rely on suncertify.db.Data class to interact with db.db. This will definitely involve more careful thoughts on implementation of the Data class.
I rush this post and may not present the idea clearly. Welcome clearer thoughts here.