Since I'm using RMI the locking strategy is based on the fact that only the thread that locked the record can unlock it.
This would be fine if the RMIRegistry does not use a thread pool to service requests. Obviously, a thread pool would mean that a different client could be assigned the same thread and could therefore unlock a record that it didn't lock. The worst case would be if the Registry server was not multithreaded and only used ONE thread for all clients (I know this is unlikely but it is an implementation detail), since this would mean that every client could unlock any record they choose.
There is also the side issue of a reference to the thread remaining in the HashMap until a client unlocks the record. This could result in a memory leak as a dead thread could not be garbage collected.
Originally posted by Steve Granton:
Thanks for the help and the ideas. As I thought, time to rethink my locking strategy!!! :-)
Maybe the moderator of this forum can move this to the Developers Certification forum so others can benefit.