Safe server shutdown
I will try to explain what I understood are the things we need to do for safe server shutdown. Please comment on it.
1. While the server is running, if the CSR presses Ctrl-C or HaltServer button on the GUI, then the server should shutdown gracefully.
2. What I understood by the term "gracefully" is: (a) No new clients are allowed to get a reference to Adapter from ConnectionFactory. (b) Allow some time(Maybe, sleep for a couple of seconds to let the current threads complete their work) and then exit using System.exit(0).
3. This is achieved by Runtime.addShutdownHook()[i.e. do the sleep thing here and do not allow new clients]
4. I have gone through many of the past posts but could not understand the reason why they are locking the complete database. I mean if you're not giving access to any new clients then its OK right? What is the point of lockdown the complete database while you're however shutting down the JVM?
5. I also saw some of the posts discussing about lock(-1) call. What is it about? I am guessing it is regarding old assignment.
Originally posted by Don Wood:
Hi Satish,
My preference is different from 2b and 3 (see below). I just don't like idle timeouts hoping that the timing is right. Most of the time, the time out is wasteful as nothing is going on. When you do need it, how do you know that the 1 or 2 seconds is enough?
Considering the worst possible time to complete a single operation, I guessed that it should not take more than a couple of seconds to perform a operation(reading/writing/deleting). I know this does'nt sound like a technically right approach, but...
As for question 4, the reason some people are locking the complete database is to ensure no transaction is cut off in mid stream. No new requests can come in but the issue then is when are the threads that are already in going to be done? One thorough but slow approach is to lock every record. This is probably a fine solution for this assignment.
I thought if NO new clients are coming, then obvioulsy no all new requests are stopped right? However we want to let all the correct working threads to complete their operations.
Oh, I get it. Say suppose if 3-4 threads are waiting on a record and if shutdown the server, we just want the currently operating thread on the record to complete and not any new threads to do any further operations. This might be the reason to lock the complete db and then shutdown the JVM.
The answer to question 5 is yes, the lock(-1) is for an old assignment but the concept is relevant for server shutdown.
Yeah, I too thought that its for the old assignment.
A Different Approach
I had my idea mostly worked out when I found this thread which is pretty close to what my plan is. See Robin's post. There's not a lot of details but you don't need all that much to make it work.
Lock Db
Don, thanks alot for pointing out to this thread. Its a very good approach. BTW, at first I implemented lockDB and unlockDB for reading and creating records besides the given locking. Later I thought locking/unlocking compelte DB is'nt required for reading/creating and took out the methods. Now, I think this is the time to revisit those two methods and refactor them accordingly.
What I like about this approach is that we can make the shutdown event driven. Once we know all the threads are out we can shutdown. Most of the time this will be immediately. When it is not, we can still shut down as soon as the last record is unlocked.
I still need to workout(basically think alot on this) on this and do accordingly. The thing is this fancy server shutdown and client crashes dealing though is not required, I think doing them is good not only for exam point of view, but personally also.
I thought if NO new clients are coming, then obvioulsy no all new requests are stopped right? However we want to let all the correct working threads to complete their operations.
Oh, I get it. Say suppose if 3-4 threads are waiting on a record and if shutdown the server, we just want the currently operating thread on the record to complete and not any new threads to do any further operations. This might be the reason to lock the complete db and then shutdown the JVM.
I still need to workout(basically think alot on this) on this and do accordingly. The thing is this fancy server shutdown and client crashes dealing though is not required, I think doing them is good not only for exam point of view, but personally also.
Originally posted by Don Wood:
Javini,
Your point is well taken. Perhaps it wasn't said very well above but the idea is to let any clients that have locks complete their requests.
That's exactly the idea Don.
So a client that held a record lock would continue with that request and subsequent requests until it unlocked the record. No new locks would be accepted.
Exactly Don.
I haven't thought far enough ahead to decide whether or not I will allow a client that does not have a lock to complete requests that do not require one (such as a read).
I want to allow read/create operations if there are any as they do not need any locking and if we stop in the middle, clients may get corrupted information or corrupted data will be written to the file.
I think I would like to allow only clients with locks to continue but I'll have to decide that when I get to the implementation.
I did not find shutdown server as a requirement, perhaps I am missing something here?
Bring me the box labeled "thinking cap" ... and then read this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|