On @Cacheable annotation of Spring

The @Cacheable annotation of Spring works like magic, allowing us to create caches easily with just one line of code.
But it is important to not that the caching will NOT work if you are calling method is in the same class !
This happens because Spring injects a proxy at runtime to implement caching and if you are making calls to cacheable methods from the same class, the proxy is not used.

More information on this thread - https://stackoverflow.com/questions/16899604/spring-cache-cacheable-not-working-while-calling-from-another-method-of-the-s

ETag response header

HTTP 1.1 introduced a new kind of cache validator i.e. ETag.

ETags are unique identifiers that are generated by the server and changed every time the resource is updated. An ETag is a string that uniquely identifies a specific version of a component. The only format constraints are that the string be quoted.

ETag: "10c24bc-4ab-457e1c1f"

The problem with ETags is that they typically are constructed using attributes that make them unique to a specific server hosting a site. So in a typical clustered environment, if the next request for a cached resource goes to a different server, then the ETag won't match and the resource would be downloaded again.

Most modern Web servers will generate both ETag and Last-Modified validators for static content automatically; you won't have to do anything.

More info about ETag can be found at the following links:
http://developer.yahoo.com/performance/rules.html#etags
http://nerdmonkey.com/blog/archives/000098.html
http://www.web-caching.com/mnot_tutorial/how.html

The advantage of ETag over the 'last-modified-date' tag is that the fact that ETags don't require a date but will take any string. So U can compose ETag with any custom logic and source.

Java Applet Caching Issues

I spent the last 3 days in frustration trying to get Java Plug-in cache mechanisms to work.
Since JDK 1.5, the Java Plug-in has advanced caching options using the "cache_archive" and
"cache_version" tags.

One particular vexing issue that I faced was that inspite of adding all the cache directives in the applet's object tag, the jar files were not cached. A quick google showed 2 bugs:
1. Unfortunately, if the servers do not return Last-Modified or Expires in HTTP response headers, it would disable plugin caching for the connection, and plugin would try to redownload the file again without caching. This results in two HTTP GET requests per file.
2. If a running applet makes a call to URLConnection.setDefaultUseCaches(false), then all subsequent loads from this plugin will exhibit the multiple-load-request behaviour.

In our case, the Applet was setting the cache as false in the code. Hence the cache directives were not working as expected. More information on this can be found here and here.