This post originated from an RSS feed registered with Java Buzz by dion. Original Post: AOP Caching Feed Title: techno.blog(Dion) Feed URL: http://feeds.feedburner.com/dion Feed Description: blogging about life the universe and everything tech Latest Java Buzz Posts Latest Java Buzz Posts by dion Latest Posts From techno.blog(Dion)

Cedric has responded to the article on TheServerSide, Implementing Object Caching with AOP.

He discusses the coupling issues that are intrinsic to any of these crosscutting problems.

The nice thing about AOP, is that it gives you the tools to add to the balance.

You can choose to:

• Use a marker based approach (@annotation / marker interface / naming convention in methods [normally bad])
• Have a more complicated policy defining a pointcut in code (e.g. List around(String productGroup) : getInterestRates(productGroup) {)
• Define a DSL in some form to handle the configuration

At the end of the day, these are all the same in more ways than they are different. Cedric says:

It should be configurable externally. You don't need AOP to branch conditionally and disable (or alter) your caching logic at runtime. Most of the EJB and web containers that I know have been providing this kind of functionality in XML files for quite a while.

This is an example of a DSL. In this case, there is a very formal way to specify SOME form of caching for EJBs. It is very limited, but it is well specified.

A lot of the time people want a lot more control (and not be forced to use EJB ;), and that is where the other options come in. You could create your own XML definition which powers the caching configuration (an Aspect could grok that), you can use annotations if you think it makes sense to declare the configurability of the caching IN the area of the code, or you can modularize it completely by NOT having this, and having it all in an external aspect. At this point your code doesn't know about the caching cross cutting concern.

In my opinion, there is no RIGHT answer for all of your needs. As with all these things, depending on your use cases, you will find the right balance.

We added Tangosol Coherence to the TSS code way back, and we only needed caching in the form of DATA caching. Thus, we could add it to our persistence layer, in one simple place, and the AOP approach may well have been overkill here.

But there are many other types of caching, and I think an AOP modularization of this concern makes a lot of sense.