Greetings to everybody! I finally post my first message after being quiet for a while. This is a very good site and I am quite impressed by a number of kind and friendly names here (like Nate, Michael Morris, Mark, Eugene, ...). I like this site. Well, I'm also in the process of completing the project. As I find, many of the discussions here about the locking mechansim is to use a LockManager where a private HashMap is kept. This LockManager is instantiated once and passed to all client connections, in such a way all clients share one instance of LockManager to manipulate the locking. This is fine if *users of db.db* all go through this logic. By users of db.db, I mean a much wider scope than the client that we are currently talking about. To make it clear, I think I need some elaboration on this. 1. I would define FBN User as the user of the FBN Client GUI. 2. I would define DB User as the user of the db.db. It's obvious that FBN User is only a fraction of DB User. For example, there may be other projects communication with db.db and they may not use the objects, classes defined in FBN project. They may completely implement the communcation with db.db using separate approaches. This means the Lock Mechanism in FBN project may have no effect at all. Other DB User can modify db.db at their own will. Let's examine the weakness of FBN LockManager first. The HashMap (or sth else) storing all the locks resides in memory -- the locks are not physically implemented. You know the lock's info only when you read the memory, which other DB users cannot. What can we do here then? Of course, we have no control over any of other DB users. But we can certainly make our locking more powerful. If you want have effect on other DB users, we have to assume that all DB Users at least will use suncertify.db.Data class to interact with db.db. This assumption is meaningful as that class is the base for us all. Now, our DB Users is limited to users who use suncertify.db.Data class to talk to db.db. Still, this version of DB Users has a much wider scope than FBN Users and the previous Lock Mechansim may not have effect to them. However, we can achieve this by physically marked the records as locked in db.db. We may define LOCKED_RECORD (e.g. = 2) in addition to the orginal ACTIVE_RECORD and DELETED_RECORD in the Data class. Whenever a record is locked, just marked the first byte as LOCKED_RECORD. In this way, we need to modify the Data.modify method to accommodate this new status. By doing this, at least other DB Users know the lock. Have to have dinner... I will follow this up. My thoughts on this is still not well-formed and I definitely welcome your comments and additions.
You have a valid concern. However, IMO, I don't think you need to worry about this for the SCJD.
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. Eugene.
Joined: Oct 14, 2002
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.