1.I used a HashMap to cache the recNo and the records. But I am not sure this design is ok or not. I tested by launching 2 program of "Non-Networked Mode". When I booked and updated one record, the other program could not display the updated records since the cached map is used in the design and the program just dispay the cache. This happens in launching serveral programs of "Non-Networked Mode". Is this design ok?
2. For the "server-client" system, assuming user "A" books one record and doesn't release it and at the same time there is another user "B" want to lock the same record, but "B" should wait since the record have been locked. Should "B" wait forever if the record is not released by "A"? So if "B" click the record and click button "book", the "GUI" just wait......for ever until "A" release the lock. Is this design ok?
Could anyone give me any advice?
I am not sure the design/concept is ok. I appreciate if anyone could help ASAP.
1) In non-networked mode the requirements (at least mine) clearly state there will never be more than one client using the datafile at any time.
That said, a forced refresh of the data should at all times retrieve the current status, not something that's cached somewhere.
Of course the client maintains a cache in the datastructure it uses to display the records, but that should never be relied upon to be accurate. What I do is reread any record selected for reservation and then reread it once more between the time I lock it and the time I update it for a final sanity check to determine if it's still the same as it was. If you lock the record immediately prior to reading it for editing that last step isn't needed of course.
2) That's what the requirements say when you read them literally, though it's advisable to build in some safeguards to protect against it (just in case a client were to crash or loose its network connection while holding a lock). But do explain that decision carefully.