Modify session or re-fetch from database

[c chapman]

A jsp page displays a list of customers from my database. You can delete one or multiple customers from this page. Upon deleting I want to return to the same page reflecting the new list of customers. I'm not sure whether to store the customer list in the session scope and amend the list after deletion (in addition to deleting from the database) or just delete from the database and re-fetch customers from the database. The first option saves the overhead of connecting to the database each time but I'm not sure how safe it is.

Thoughts?

[Bear Bibeault]

If you implement this using a "lazy caching" pattern, you get the best of both worlds.

[c chapman]

Thanks Bear.

I'm not entirely sure what you mean by "lazy caching" or how I go about that. Any pointers or useful resources?

Ta

[Bear Bibeault]

Essentially you create an object that abstracts your data. When you ask for the data it checks to see if it has it cached, and if not, it fetches it. When something happens that changes the data, this object is informed and it flushes the cache. So the next time something asks for it, it gets read back from the DB.

You can make this object as smart or as simple as you'd like.

The great part is that it shields all the rest of your program from having to know details of how and when the data is fetched.

[c chapman]

That sounds similar to my approach. i.e I have a Customer object that represents a row from the customer table. When fetching the customers from the db based on the search criteria, I populate a List with Customer objects and set (cache) the List in session scope.

The only time I want to return to the display page is when the data has changed e.g customers deleted or amended. So, based on what you say, I should fetch from the database. In which case, I don't need to store the List in session scope, request would do.

Have I understood you correctly?

[Bear Bibeault]

If you store the cache in request scope it will need to be recreated with each request, which eliminates the reason for caching in the first place.

If the data is user-specific, I'd use session scope. If the data is user-agnostic (the same for all users), I'd put the cache in application scope.

[c chapman]

So, I should have the entire customer table (a collection of Customer objects )cached (session scope is appropriate) and use the cache when performing searches, until the data changes, at which point I flush and restore the cache?

I can see how this will reduce the amount of sql in my application and reduce database queries.

Thanks Bear.

[Bear Bibeault]

Not necessarily the entire table -- which might be too much data, or needless. Depends upon your application. Again, one of the beauties of this technique is that it abstracts caching particulars away from the rest of the application so that any decisions you make about what makes the most sense to cache or not cache are not a concern to anything but the "cache manager" object.

[c chapman]

Thanks for all your help Bear. Very helpful and timely responses. I've got a good idea what path to go down now.

Cheers,

C

[Kutub Shaikh]

sorry