• 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

How to keep clients up-to-date?

 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I have a problem that is hard to explain, so the vague subject. I am not even sure if this is the right forum (if not, please move as appropriate.) So please bear with me with the explanation.

Approach 1. I have a servlet that, when called upon, creates a new bean (let's call it bean A for later reference) and saves the bean in the session. This bean A will 1) use DAO to get and save records and 2) handle logic. JSP will use the session saved bean A for it's display.

All is well.

Approach 2. Then I read about the pagination discussions/faq/articles on the ranch and thought maybe what I did was wasteful (in terms of database access). I have a small set of records, less than 500 for sure, mostly around 100. I thought, maybe using the greedy approach, I can keep all the records in the bean A, instead of fetching the data each time. I only need to find the right slice when doing the pagination.

But by doing this, any update to the database will not affect what the clients see, unless he quits the session.

I think this is a very common problem.

I can, of course, go back to approach 1 and return limited records based on page. But I am very curious what are the techniques or patterns people use to handle approach 2.

Thanks,
Ben
[ November 07, 2008: Message edited by: Ben Zhang ]
 
Ben Zhang
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Allow me to elaborate some more.

The update will happen sparsely, so approach 1 still is wasteful. There is really no need to go to the database when client just browsers through the pages, most of the time.

Somehow I think there should be some kind of object that tells all the clients that there is an update to the database so next time you should not use the save bean A, rather, get a new one.

Thanks,
Ben
[ November 07, 2008: Message edited by: Ben Zhang ]
 
Sheriff
Posts: 13411
Firefox Browser VI Editor Redhat
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You might want to read up on the "Monitor Pattern".

With this pattern, objects register themselves with other objects as listeners to be notified when a particular event takes place. If your cache bean were to register itself with whatever object it is that writes to the database, it could be informed that a change has taken place so that it will know to refresh itself before returning any more data.
 
Bartender
Posts: 4179
22
IntelliJ IDE Python Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
And another approach (if the DB update is out of the web application's control - so the Cache can't be notified of changes) would be to store a timestamp when the DB is updated. Your cache would store a timestamp for the last time it pulled data from the DB. When a new request for data comes in the Cache would first check the timestamps - which should be a relatively quick operation. If the cache timestamp is >= db timestamp then provide the cached results. Otherwise, get new results from the DB, cache them, update the cache timestamp and return the new values.
 
Ben Zhang
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you both for your suggestions. I will go study them.

Ben
 
Ben Zhang
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I would like to get some clarifications from you for my further pursue of the problem.

1. Ben's approach:
I have been doing lot's googling but could not find much information on the Monitor pattern. Most of them talk about its usage in GUI where an object listens to, e.g., button event.
But there is something about publisher-subscriber. Is monitor pattern synonyms with the publisher-subscriber pattern? How about the observer pattern? Do you have a link about the monitor pattern (cannot find from pattern FAQ. By the way, some links in design pattern FAQ are broken)?

2. Steve's approach:
This approach is simple and straight forward. My concern is, a database trip to get one field (time stamp) of a row, v.s. get a whole row, and maybe do query on another table, it is definitely cheaper. But still, the overhead of getting jdbc connection, running query, and closing connection, I don't have a good grip of how big it is. Could you please elaborate more?

Thanks,
Ben
 
Ben Souther
Sheriff
Posts: 13411
Firefox Browser VI Editor Redhat
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, the Observer pattern is what I meant.
 
reply
    Bookmark Topic Watch Topic
  • New Topic