Thanks for a nice example, I have a requirement to load 20000 String objects into memory refresh them into memory once everyday.

Is it possible using above solution ?

AOP is not very helpfull for code maintenance, because your business code gets altered through compilation and eventually does not do what you expect, when you run it. You always have to have in mind, whether there is AOP code that alters the original code. But within caching it seems a good trade off. Just make sure code is well commented.

One hint from my experience: Don’t start with database caching .. your performance may have a severe drop. Start with memory cache and put only those objects in the db, you really have to.

I have published some of my understanding on J2EE Design Patterns at

http://context2designpatterns.googlepages.com

thanks.

thanks for your feedback!

Yes, you are right – if you have to apply different Interceptors to different ‘Providers’ programmatically than you may end up with a lot of delegating code.

One possible solution to reduce delegating code, could be a more generic way in that you’ll use a dynamic proxy or CGLIB and intercept (or ‘overwrite’) only those methods where you are in need of custom cache logic.

Greetings

Mario

I see your point of making a more programatic cache instead of a fully generic one which may need certain logic to “cache” or “not cache” some objects.

On the other hand (I know this is just an example….) you are intercepting a dao implementing its interface and you would be needing lots of classes to apply your cache in different points of your application. That could lead us to a hard to maintain app. What do you think about that?

Nico