HTTP Caching Headers

I recently wanted to add some rather aggressive caching, to prevent my server getting hit too often.

Naturally, I wanted this caching to take place on the client, i.e. the webbrowser.

So, there have traditionally been advantages and disadvantages to caching.

Advantage: the server doesn't get hit again, and your website feels more responsive.

Disadvantage: it is possible to see outdated cached data.

Invalidating cache entries is basically an entire study of its own.

In my case I took the obvious route: the data stays the same forever.

This facilitates my caching wonderfully.

response.addHeader("Cache-Control","private, max-age=31536000");

This stores the item in the cache for one year (31536000 seconds).

Private means caching in the client browser, public means that it might also be elligible for caching in all other intermediaries between de browser and the server.

The blogs in the references are very clear.

References

[1] Heroku Dev Center - Increasing Application Performance with HTTP Cache Headers

https://devcenter.heroku.com/articles/increasing-application-performance-with-http-cache-headers

MDN Webdocs - HttpHeaders - Cache Control

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control

MDN Webdocs - HTTP caching

https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching

Hibernate and Caching

One of the major problems of debugging, is that sometimes there are bugs, but they only happen some of the time¹.

This makes it hard to fix, unless you can spot the pattern required for the bug to appear.

The Problem

My colleague at work had such a one.

Sometimes the software threw an exception and complained that the table in the database did not actually exist. Sometimes the program provided the data required, and went merrily on its way.

It's crazy for a database table to exist only some of the time.

It made sense in this case that the table didn't exist. Because that table wasn't in the database. The Entity was purely used as a 'View' and several methods gathered the information to load an instance of the Entity.

The Explanation

Hibernate provides caching, meaning that a lookup by Identifier for an Entity returns the Entity from the Cache without hitting the database, if the Entity has been loaded already once.

Turns out our method, which loaded an Entity, totally didn't work at all! It just happened to return a Cached instance in some cases without problems.

A cached instance that was loaded by using another method that did not rely on findByIdentifier (for example via "select new Constructor()").

References

[1] The Kingdom of Transformation

http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audience/The%20Kingdom%20of%20Transformation.html

[2] Hibernate - Object Identity

http://docs.jboss.org/hibernate/orm/4.3/devguide/en-US/html/ch02.html#d5e824