Cross cutting concerns
Most developers will acknowledge how implementing crosscutting concerns such as logging, auditing, security and transactionality can adversely affect business logic implementation. Such concerns “seem” to increase the complexity of existing business logic, at times making it difficult if not impossible to clearly distinguish business logic from the crosscutting concern implementation.
Spring is very good at cross cutting concern (CCC) allowing developer to use or implement cross cutting concern as abstract as possible.
i have never thought of cache as cross cutting concern but caching abstraction by spring is really isolating caching and business logic/navigation (screen) logic in such a way that allows developer to only focus on logic rather than caching implementation like transaction.
before we move to usage part difference between cache and buffer needs to be clarified.
Cache vs Buffer
The terms “buffer” and “cache” tend to be used interchangeably; note however they represent different things. A buffer is used traditionally as an intermediate temporary store for data between a fast and a slow entity. As one party would have to wait for the other affecting performance, the buffer alleviates this by allowing entire blocks of data to move at once rather then in small chunks. The data is written and read only once from the buffer. Further more, the buffers arevisible to at least one party which is aware of it.
A cache on the other hand by definition is hidden and neither party is aware that caching occurs.It as well improves performance but does that by allowing the same data to be read multiple times in a fast fashion.
The abstraction applies caching to Java methods, reducing thus the number of executions based on the information available in the cache.That is, each time a targetedmethod is invoked, the abstraction will apply a caching behaviour checking whether the method has been already executed for the given arguments. If it has, then the cached result is returned without having to execute the actual method; if it has not, then method is executed, the result cached and returned to the user so that, the next time the method is invoked, the cached result is returned. This way, expensive methods (whether CPU or IO bound) can be executed only once for a given set of parameters and the result reused without having to actually execute the method again. The caching logic is applied transparently without any interference to the invoker.
Obviously this approach works only for methods that are guaranteed to return the same output (result) for a given input (or arguments) no matter how many times it is being executed.