When your RMI connection breaks and your server attempts to clean up its locks the server must attempt to unlock ALL locks because it does not really know which record(s) your connection actually locked. Correct?
No. You must track client identity to satisfy the requirement that a client may lock() a record twice without ill effect. The identity tracking will also help clean up exactly those locks held by the now-defunct client.
I will leave it up to you to decide whether you need a map or not - there is more than one "right" design.
Originally posted by Michael Morris:
Is it necessary to Map clients to records in the LockManager? If so should you use a WeakHashMap? If you don't use a WeakHashMap and the client dies, when will unreferenced() be called by RMI?
That is a dangerous assumption to make, especially in view of the reusability requirements for the database implementation. Surely future applications making use of the database might well need multiple locks.
Originally posted by Sai Prasad:
Just one comment about Peter's posting. At any moment in this locking process, any one client will be associated with only one lock.
Every client gets its own server-side Connection object to talk to; this object is its gateway to the database. From the lock manager's point of view, the Connection is the client identity. Assuming that your lock manager needs to map records to the client holding the lock on the record in question, this can be done using a Map mapping Integer record numbers to the Connection object for that client.
Just one question, any possibility Connection extends Data, I mean is Connection a.k.a. RemoteData ?
So what the Connection object does is delegate calls to its lock(int) method to, for example, a LockManager instance that has a lock(int, Object) method, the Object being an object that identifies the client. In this case, the Object being passed in is... the Connection itself!
That's essentially it. You can add some bells and whistles -- for example, the Connection object could enforce that you must have a lock in order to modify a record, or perhaps even acquire and release a temporary lock if the client doesn't have one already. But in the assignment such frills are strictly non-essential.
Originally posted by Andrew Collins:
Should I then wrap a Data object within Connection and delegate all method calls, except for lock and unlock ?
Also, if you do not implement locking for local mode, than your client cannot do a "lock-read-write-unlock" safely if multiple threads run this sequence
The is absolutely NO LOCKING in local mode. In local mode the app has exclusivity to the Data classes and db.db file.
What am I missing here?
Please let me save you.
Taj Mahal is 7 lines of code in Lock() of Data, and 2 lines of code in unlock()
And if you have any lock or unlock at all in local mode they will not give you 155/155.