Unfortunately this means that the size of the lock list is directly proportional to the size of the data - this approach is unusable in any "serious" database. Arguably, it is fine in this case because Data breaks down on large data sets anyway (esp. the find methods). Nevertheless it is easy to make a strong case for a Map.
Originally posted by Gennady Shapiro:
2. Consider an ArrayList instead of a Map. ArrayList gives you direct indexed access to your lock object, where number of the record is , in fact, its index in the list. The Map will have to calculate hash index of your lock object every time you use it, making a performance hit.
Heartily seconded on the first point. I wouldn't replace a synchronized Map by a Hashtable, by the way; Hashtable's API is a mess because the Collections API is kludged on top of an existing object. I'd always recommend native Collections objects such as HashMap over the old-style Vector and Hashtable.
P.S. Why do people insist on using synchronized Maps when they are being accessed only by already synchronized methods? Besides, syncronized HashMap = Hashtable.
Originally posted by Peter den Haan:
[B]A particularly elegant solution is to give each client its own Connection remote object that implements the DataInterface. This solves all your problems in one go without unnecessarily burdening the client code with tokens, additional arguments or whatever. After all, the Connection on which the method (lock, unlock, add,...) is invoked is the client identity you're looking for.
Originally posted by Mark Spritzler:
Jason, the connection object is not bound to the Registry. If that helps out, the other thing to check out is O-Reilly's book on RMI. That is how I got over the same question that you have.