Featured Article: Implementing Caching with AspectJ

Discussions

News: Featured Article: Implementing Caching with AspectJ

  1. Adrian Colyer has started a mini-series of blog entries that examine some common aspects such as caching, pooling, auditing, security, persistence, and so on. He shows you how to implement them using AspectJ. The first 2 parts in this series look at caching, with extensive code samples.

    Read Implementing Caching with AspectJ

    Threaded Messages (16)

  2. If you take the sleep() calls out, it will speed it up without having to cache anything ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  3. Idea of applying AOP to general caching problem is not new and has been floating around for quite some time. But it always gets a lot more interesting when task is elevated from a toy example to a real life scenario. For example, how AOP is applied to arbitrary cache transaction demarcation? How to provide custom handling for exception?

    Best regards,
    Nikita Ivanov.
  4. Probably nobody caches data if transactions are very importatnt for this data, but it is possible to implement transaction cache too. Transactions are demarcated outside data access code, it is good a idea to map it to thread (java.lang.ThreadLocal). It is possible to demarcate transactions per method AOP, can help to do it too, but I think it is not a good idea, I prefer to execute all data access methods in the same transaction (there is some domain specific exceptions in this rule too).
  5. transaction demarcation[ Go to top ]

    Idea of applying AOP to general caching problem is not new and has been floating around for quite some time. But it always gets a lot more interesting when task is elevated from a toy example to a real life scenario. For example, how AOP is applied to arbitrary cache transaction demarcation? How to provide custom handling for exception?Best regards,Nikita Ivanov.
    We've got that too. Still needs JDK 1.5 annotations, but I'll be adding that for the next release.

    JBoss AOP has aspects for:

    * transaction demaracation
    * role based security
    * asynchronous in-VM communication
    * caching
    * remoting (clustered and non-clustered)
    * transactional locking
    * read-write lock

    Bill
  6. transaction demarcation[ Go to top ]

    Idea of applying AOP to general caching problem is not new and has been floating around for quite some time. But it always gets a lot more interesting when task is elevated from a toy example to a real life scenario. For example, how AOP is applied to arbitrary cache transaction demarcation? How to provide custom handling for exception?Best regards,Nikita Ivanov.
    We've got that too. Still needs JDK 1.5 annotations, but I'll be adding that for the next release.JBoss AOP has aspects for:* transaction demaracation* role based security* asynchronous in-VM communication* caching* remoting (clustered and non-clustered)* transactional locking* read-write lockBill
    Sorry, and the link is:

    http://www.jboss.org/wiki/Wiki.jsp?page=JBossAOP

    Bill
  7. transaction demarcation[ Go to top ]

    Hi Bill,
    I haven’t look at JBoss Aspects for caching so I’m taking an educated guess here. Since Java doesn’t have closures JSR-175 annotations (or more generally cross-cutting) can be applied only to a limited set of language constructs - class, interface, field, method, parameter, constructor, enumeration, or local variable (note that non JSR-175 implementations are even more limited to basically method calls).

    That is rather limiting in my view because it doesn’t allow me to just start cache transaction in the body of the method and artificially pin my transaction demarcation to a language structure – basically methods.

    General distributed caching is essentially one of many examples where I don’t see any AOP advantages over proper designed OO approach. It seems rather like a solution for a problem that does not really exist. I can see, however, certain use of JSR-175 based cross-cutting for very coarse grained caching application, let say in JSP or EJB-like designs, but it is hard for me to say (at least now) that AOP approach is much better (if better at all) than traditional OO design. In fact, blunt reduction of LOC has very little direct impact on usability, readability and robustness of the code.

    Regards,
    Nikita Ivanov.
  8. transaction demarcation[ Go to top ]

    Hi Bill,I haven’t look at JBoss Aspects for caching so I’m taking an educated guess here. Since Java doesn’t have closures JSR-175 annotations (or more generally cross-cutting) can be applied only to a limited set of language constructs - class, interface, field, method, parameter, constructor, enumeration, or local variable (note that non JSR-175 implementations are even more limited to basically method calls). That is rather limiting in my view because it doesn’t allow me to just start cache transaction in the body of the method and artificially pin my transaction demarcation to a language structure – basically methods.General distributed caching is essentially one of many examples where I don’t see any AOP advantages over proper designed OO approach. It seems rather like a solution for a problem that does not really exist. I can see, however, certain use of JSR-175 based cross-cutting for very coarse grained caching application, let say in JSP or EJB-like designs, but it is hard for me to say (at least now) that AOP approach is much better (if better at all) than traditional OO design. In fact, blunt reduction of LOC has very little direct impact on usability, readability and robustness of the code.Regards,Nikita Ivanov.
    I'm not exactly sure what you're trying to say. JBoss Cache can work off of a JTA TransactionManager. So, it doesn't matter where you begin a transaction, with JSR-175 or a UserTransaction. JTA associated a Tx with a thread (and disassociates). JSR-175 is not used at all within our caching stuff. It is used for transaction demarcation (similar to EJB demarcation except available at constructor/static method/member method level), security, tx locking, asynchronous, etc... go read our doco before you judge too much.

    Bill
  9. transaction demarcation[ Go to top ]

    General distributed caching is essentially one of many examples where I don’t see any AOP advantages over proper designed OO approach. It seems rather like a solution for a problem that does not really exist.
    You are right, good C programmer can say the same about OO too. As I understand AOP is a language level design pattern, but it is a good one.
  10. There's an important point that I don't want to get lost in the discussion here. Strange as it sounds, one of the things I didn't do in the blog entries is actually implement a cache. Instead the examples show how you can use aspects to implement caching using an existing cache implementation. I just used HashMap because it was easy, but in a heavy-duty caching scenario you'd want a cache with storage management, expiration policies, concurrent access support, maybe replication,... and so on. If you need that, the JBoss distributed cache may be an excellent choice (I don't know, I haven't used it personally) The SimpleCaching aspect doesn't care what you choose.

    Rather than being a cache (in which case you'd expect to see a class named something like SimpleCache), what the Simple*Caching* aspect encapsulates is the protocol for using a cache (the cache you configure it with) - namely look in the cache first, if you find it, great, if you don't, go get the value and put it in the cache for next time before returning. SimpleCaching encapsulates the caching protocol.

    That said, there are plenty of programs out there that do use a simple Hashtable or HashMap to implement basic caching (from the factorial program based examples you were taught to write in CS on upwards). In this sense, when configured with a HashMap, SimpleCaching is useful in the sense that it makes caching an abstraction you can just use (like you might use a List). So in my factorial program I can write three lines of code and be done with it:

    aspect FactorialCaching extends SimpleCaching {
      pointcut cachedOperation(Object key) : execution(* Factorial.factorial(int)) && args(key);
    }

    I can also see the case for the annotation-based approach here, where I just write

    @Cached
    public BigInteger factorial(int x) {...}

    in the Factorial class, and have a more general purpose aspect using a pointcut matching on join points with the "Cached" annotation:

      pointcut cachedOperation(Object key) : execution(@Cached * *.*(..)) && args(key);

    (The AspectJ syntax for using annotations in pointcuts is not yet defined, but we will be working on it as part of our Java 1.5 support).
  11. I can also see the case for the annotation-based approach here, where I just write@Cachedpublic BigInteger factorial(int x) {...}in the Factorial class, and have a more general purpose aspect using a pointcut matching on join points with the "Cached" annotation:   pointcut cachedOperation(Object key) : execution(@Cached * *.*(..)) && args(key);(The AspectJ syntax for using annotations in pointcuts is not yet defined, but we will be working on it as part of our Java 1.5 support).
    I think it is a good way, declaration says "what" and aspect says "how". Aspect implementation is reusable and it makes programming more declaratyve. Some aspects can be used to implement method itself,query languages for data access are declaratyve too and I think it is a good example :

    @Cached
    @Query "SELECT something"
    //@Transactional is not a good idea in this case
    abstract Collection findSomething();



    I think this kind of language level AOP can be very powerfull.
  12. JBoss Cache AOP[ Go to top ]

    Check out JBoss Cache AOP. We've actually implemented a distributed, transactional cache based on our AOP framework. Its been in 1.0 for a few months now.

    http://www.jboss.org/products/jbosscache

    http://www.jboss.org/developers/projects/jboss/cache/TreeCacheAop.html

    Bill
  13. JBoss Cache AOP[ Go to top ]

    Check out JBoss Cache AOP. We've actually implemented a distributed, transactional cache based on our AOP framework.
    Of course, "distributed, transactional" here means "distributed XOR transactional". Hard to spot, rarely advertised, but it's mentioned in TreeCache documentation - chapter "Overview", last paragraph.

    I do understand why you made such a choice, though.
  14. JBoss Cache AOP[ Go to top ]

    While we are in to blatant product marketing, there are two main issues that any Java caching implementation struggles to deal with:

    1. Guessing how much memory a cache is using (if you get this wrong, you may not only hurt your application's performance (through excessive gc), you could run out of memory!

    2. Course-grain eviction policies - why hope that an LRU or LFU eviction policy is always going to keep important objects in your cache before an eviction ???

    Well, we've gone along way to solve these fundamental caching issues:

    http://www.ebizq.net/news/4731.html
  15. JBoss Cache AOP[ Go to top ]

    While we are in to blatant product marketing
    A little marketing, but the blog talks about how you could do caching. We've actually done it. Since we're open source, you can take a look....

    Bill
  16. Product placement[ Go to top ]

    Why is it that I never see the people who write the most popular or well respected software tools in the J2EE community pimping their product ad nauseaum when anyone posts an article even slightly relevant to the use case of their tool? Where are the 5 posts by Rod pimping Spring when someone mentions IoC? God forbid you mention MVC or you will get spammed by WebWork people. Bill... software respect spreads by word of mouth, not incessant marketing.

    /9
  17. Product placement[ Go to top ]

    Yep I'm pimping, I started the reply by warning you I was doing it. So you can either mark my post as noisy or move on (by not ignoring me you gave my blatant product placement more oxygen, so thanks!).
    My post was part ironic, cause it's a bug bear of mine that threads get hijacked by rival this or that (though I think I may even be guilty of the same in the very distant past) - and it's nice that you seem to agree with me.