This is just a quickie post with some notes about caching. The subject has been covered in great detail elsewhere (see links below) so I will leave the heavy discussions to them, but wanted to point some things out.
Caching strategies can form an important part of the performance and scalability of your system. Caching can also cause problems when it is not stored or cleared correctly: cache invalidation is a hard problem.
There are multiple levels to use cache in a system (all of which can be cached and cleared):
session storage (HTML5, client side application level cache)
spring cache (service layer)
Hibernate L2 cache (data layer)
For RESTful web apps, the argument can be made that we should consider the browser to be the cache, and the application should be in the business of computing cache keys, not actually caching. More on that with the discussion here (this is my handy link of the week).
If computing ETags is what you want to do there is a way to use a servlet filter to compute ETags. This saves on bandwidth but not on computation. The discussion above notes: in an era of mobile phones with iffy connections, it’s often worth it for the end-user experience to go compute a complete response just to tell the caller 304 NOT MODIFIED
Finally, here is another more sophisticated etag technique with Spring.
Again, this is just a quick summary of caching levels and some handy links. We may go into more detail with some of this later 🙂