I use "rwd".
I did not find shutdown server as a requirement, perhaps I am missing something here?
If this is indeed the problem, you need to use a different file name since you should not have a class the same name as one in the sdk. Whatever the file name is the public class or interface name must exactly match
Really, I just laughed out for sometime when reading this. Sorry about that. Yeah, I know that we should not use any class names that match with SDK. I know you just want me to make sure that whether am sticking for this rule. Thanks for the concern.
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.
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.
To answer your question: what happens to concurrency if the inner lock is not available? I'd say not much, if the lock is not available, the dataCore object is already busy reading, writing, or both.
Finally, concerning the creation of new records. If the policy that allows a new record to over-write a previously deleted record is active, then the database does not care at all about the contents of a deleted record; if the record is deleted, then it is locked, and then it is written over (and its contents are not important). If no re-usable records can be found (that is, the database contains no deleted records), then the new record is created at the end of the file.
So, here is what I will probably do. I will state that allowing new records
to over-write previously existing records may not be logically sound, and
that I don't know the philosophical or logical answer to this question. It is the customer's responsibility to configure the database in a safe
manner, and the customer does this by setting up the server and stating
what the policy will be by chosing one of the following choices from the
1. The database will allow the creation of new records to over-write
previously deleted records.
2. The database will only write new records at the end of the file.
Dead-locks are avoided by following the locking order rules: always
lock LockManager, then lock MicroData.
Usually, of course, clients are
operating outside of MicroData, first using the lock manager, then calling
Data.someMethod() which in turn calls the appropriate methods in MicroData.
In general, and keeping in mind that I don't know yet that my
code is free of dead-locks, I'd give the hint that update()
need not call lock() and unlock() at all.