3 Replies Latest reply on Aug 29, 2005 12:53 PM by starksm64

    Persistence/Caching interceptors

    ovidiu.feodorov
    ovidiu.feodorov Aug 29, 2005 12:25 AM

      It would be nice, and actually not only nice, but the the natural way to do it, to have a PersistenceInterceptor and a CachingInterceptor (or even a single interceptor that combines these two). However this is currently difficult to do, because the interceptor will replace the javax.jms.Message argument of the invocation with a org.jboss.messaging.core.MessageReference, and a whole set of server-side facade interfaces have to be changed.

      Maybe this is a sign that the current architecture based on server-side delegates is not the best one ...

      • 3576 Views
      • Tags:
        • 1. Re: Persistence/Caching interceptors
          starksm64
          starksm64 Aug 29, 2005 12:29 PM (in response to ovidiu.feodorov)

          Its important to consider whether or not the aop framework can be plugged into any service component. What can be externalized/customized via an interceptor/advise on a call path is something we need to consider if we are going to get max reuse of both existing aspects as well as the extensibility to allow for customization.

            • Actions
          • 2. Re: Persistence/Caching interceptors
            ovidiu.feodorov
            ovidiu.feodorov Aug 29, 2005 12:38 PM (in response to ovidiu.feodorov)

            We are already using AOP and we have a server-side AOP interceptor chain, which contains interceptors like SecurityInterceptor and InstanceInterceptor. So the framework to allow us to externalize aspects is there. I raised this issue because persistence/caching naturally belongs to an interceptor, and the current architecture doesn't allow me to do that easily, which is probably a hint that I have to change it.

              • Actions
            • 3. Re: Persistence/Caching interceptors
              starksm64
              starksm64 Aug 29, 2005 12:53 PM (in response to ovidiu.feodorov)

              Right, I would agree. I'm just pointing out that the first thing to consider is whether a given subsystem will lend its self to aop type of customizations. If it does not to some extent there needs to be a very strong performance/security type of reason.

                • Actions