• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Caching Records for "Bodgitt and Scarper"

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Thanks
 
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 284
Netbeans IDE Firefox Browser Debian
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Regards
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic