I just wanted some feedback on the method I am using for shutting down the server � I have read some posts on this already but just want to check two things.
For the record, I am using a RandomAccessFile to access the database with a handle on it shared between the clients. I am using RMI and start the registry programmatically.
When I am closing the server I wish to leave the database in a consistent state e.g. if three of the six fields of a record are written I want the other three to be written as well i.e. I do not want the server to shut in the middle of writing a record.
What I was thinking of doing was the following:-
1) The server will synchronize on the RandonAccessFile and once it has done so will close the RandomAccessFile and the server application � nice and straightforward! I will put a flag in the Data class e.g. serverClosing which the server will set to true before shutting down. Any public method in Data will check this flag, if it is true a ServerClosingException is thrown (I will probably wrap/chain this in an exception such as RecordNotFoundException) and this will be passed back to the client i.e. the client will see a message dialog saying �Operation failed as server is shutting down� � I will use the getCause() method to check if it is an exception of this type. The reason I put this flag in is to stop the clients competing for the handle on the RandomAccessFile so that the server can shutdown quickly. Is the method I described above ok?
2. Also from a couple of threads I have read I am a little confused as to whether or not I have to do anything regarding RMI e.g. unbind the RMI object etc. I want to keep this as simple as possible and if I do not need to do anything other that what I have described above (i.e. close the RandomAccessFile and application) then that is enough � I�m not really that interested in doing any fancy stuff if it�s not required!
I'm sure there may be lots of diverse opinions, and I, of course, encourage others to reply with their insights.
My server shuts down in a similar fashion as yours regarding the concept of a flag which the client reads to determine if it is appropriate to continue making requests of the server. In a sense, this is a cooperative agreement, and I am assuming that the clients will follow the agreement. In particular, any client before enbarking on a business method (which is defined as any number of operations on the database, which, as a whole, must succeed), should query the server before embarking on these sub-operations (i.e., this one business method).
Unlike your design decisions at this time, I do not forcibly remove anyone from attempting to use the server; it is assumed that everyone will cooperate.
If someone is not cooperating, the person shutting down the server can view the server's internals and see how many clients are waiting for locks, how many clients hold locks, and when the last disk write to the database occurred.
Any time after the system administrator has raised the flag saying that the server is shutting down, any non-cooperating client application risks harming the business as a whole if it does not cooperate, for if the server is being shut down, it will eventually be shut down, the database file closed, and the server unbound, in which case, an uncooperating client will obviously get all types of exceptions when trying to read or write to the database.
As concerns shutting down the server, I do call the appropriate method to unbind the server as the final step in the server shut down process.
Thanks, Javini Javono
Joined: May 07, 2003
Thanks for your detailed reply!
I just have a query about what you mean by "unbinding the server". Is it what I have presented below in the method unregister()? (The method register is where I bind the name to the remote object).
Regards, John [ May 26, 2004: Message edited by: John Canavan ]