Originally posted by Ian B Anderson:
[if the remote close() closes Data] then when in RMI mode other clients will get null pointer exceptions because the database file is no longer open. But if a close request is never issued then there�s not much point in having it as a method.
What should close() do? In the instructions, you are told that for networked mode you must create an object that has all the methods Data has; it stops just short of telling you that
you should have a DataInterface implemented by both Data itself and a remote-mode proxy. Implicit in this requirement is that not just the method signatures should be the same - the
semantics should be the same as well. In other words, you should call the same methods under the same circumstances regardless of whether you are working in local or remote mode.
You can easily go wrong by thinking the
behaviour should be the same, for instance, if close() closes the file in local mode, then should it do this in remote mode too? Not so. This would change the semantics of close(), because while you would still call close() in local mode you would no longer be able to do so in remote mode: as you note, it would wreak havoc with the other clients connected to the database.
Now what are the semantics of close()? It really means, "I'm through with the database, release all my resources". In local mode, the entire database is yours and it makes sense to close the file. In networked mode, the file is not exclusively yours and it shouldn't be closed. But you are holding other server-side resources that must be released when close() is called; most importantly, any remaining database locks. So there is still a lot of point in having close().
By the way, even if there wasn't anything useful close() could do in remote mode, you would still retain it so that remote and local mode would have the same interface. That's also why there are lock() and unlock() methods in local mode.
- Peter
[This message has been edited by Peter den Haan (edited October 14, 2001).]