Greg,
I'm sure I speak for many people here that your insight and responses are greatly appreciated, and I don't want you to give anything away as that would degrade the meaningfulness of the certification. I understand completely what you mean by a static reference to a group of locks, and in fact, if one uses UnicastRemoteObject, I wonder if they even need to be designated static because a single instance is used to service all client requests, but I digress...
If you have a moment, consider this scenario: a client X requests a lock on row 3. The handler thread synchronizes and wait()s. Now lets say that client X does all his modifications to row 3 and then calls unlock for row 3, which executes a notify() on that same lock object. Now presuming that lock, modify and unlock were called as 3 seperate function calls, RMI could very well have used 3 different handler threads to handle each method invocation. That means the thread calling wait() could be different from the thread calling notify(), resulting in an
IllegalStateException or the like, even if all 3 method invocations came from the same client. Now this can be handled by encapsulating the lock() and unlock() in the modify() method, but then it seems like bad judgment to expose the lock() and unlock() methods in the remote interface, becasuse they can't be guaranteed to function correctly via RMI.
As we say in my office, please tell me I'm smoking crack.
Thanks,
Rob