The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Caching Records for Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Caching Records for "Bodgitt and Scarper"" Watch "Caching Records for "Bodgitt and Scarper"" New topic

Caching Records for "Bodgitt and Scarper"

Li zhai

Joined: Jul 19, 2006
Posts: 7
Hi Everyone,

I have some question about the project.

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.

Jeroen T Wenting
Ranch Hand

Joined: Apr 21, 2006
Posts: 1847
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.

Oricio Ocle
Ranch Hand

Joined: Nov 30, 2004
Posts: 284

Hello Li zhai,
the "GUI" just wait......for ever until "A" release the lock. Is this design ok?

Prabably you are thinking that this could be easily solved starting a new Thread of execution and delegating the lock method processing to that thread.

But be aware, neglecting the event dispatch thread can arise several problems (batch updates, unsynchronized repainting,...).

My decission is comment the problem, and the solution in a real environment.

You can look at SwingWorker for more information.


I agree. Here's the link:
subject: Caching Records for "Bodgitt and Scarper"
jQuery in Action, 3rd edition