7 Replies Latest reply on Feb 4, 2005 11:57 AM by ben.wang

    TreeCacheAop object event listener


      While trying to implement http session replication (field level granularity), the need arises to listen for an object level event since we will need to update the timestamp, for example.

      I thought such event listering mechanism will also be useful for others as well. Let's say if a field has been updated, users will be interested to know about it and its associated object. So I am thinking to design it like a TreeCacheAop listener.

      Idea is to add a dynamic interceptor (of type EventInterceptor, for example) right after CacheInterceptor. So whenever, a field is accessed (get/set), it will go through the event interceptor. If the listener stack is present, it will invoke the call back to the listeners. But if there is no listener present, the overhead is the empty interceptor of which I think the performance penalty should be minimal.

      There is also the question of the Event object that get passed around. It will have information of the invoked object, the field access, and the access type (get or set).

      If a user wants to become a listener, it will implement the interface of course. Then the cache client code will need to do addObjectEventListener api to add the listener.

      Internally, the method addOjectEventListener(Object pojo, Listener listener) will add an EventInterceptor (after the current CacheInterceptor) that calls out to listener. This method can be called multiple times. Pre-condition is pojo is of class type "Advised" and CacheInterceptor has already been added.

      Any other suggestion is welcome.


        • 1. Re: TreeCacheAop object event listener
          Adrian Brock Master

          Isn't this a version of Observer/Observable?

          Except, as Bill says this should be implemented as a plain Introduction rather than
          a Mixin, such that the advice holds the Subject's observers.
          This would allow the pojo to dynamically become observable instead of
          just at weave time.

          • 2. Re: TreeCacheAop object event listener

            Guess I have never seriously looked at this pattern under aop before. :-)

            Anyway, currently it only notifies the observer that the Subject has changed. But it doesn't say what exactly is changed. For my case, I will
            need to know whether it is a field read/write and possibly which one.

            In addition, another requirement of mine is user transparency. That is a POJO writer should not need to bother with jboss-aop.xml declaration. In the case of Tomcat http session replication, I don't require a user to supply a jboss-aop.xml to put introduction in place.

            Thirdly, I am using dynamic aop to insert the interceptor at runtime.

            Do you think I still can fit these requirements into this aop pattern?

            Thanks for the suggestion,


            • 3. Re: TreeCacheAop object event listener
              Adrian Brock Master

              Your pattern is a generalization of the GOF pattern.
              You might call it FineGrainedObservable

              Just as Bill's aspect library document contains other extensions:

              I would think that the others can be implemented from the FineGrainedObservable
              simply by using different mixins for the Observer:
              GOFObserver is only interested in the Subject regardless of the field.
              TransactionalObserver enlists a synchronization to only fireChange if/when the transaction commits
              AsyncObserver uses a queued threadpool to deliver the fireChange on a different thread

              You should also be able mix them, e.g. TransactionAsyncObserver is really
              TransactionObserver and AsyncObserver where the
              Synchronization does a callback to invokeNext on the TransactionObserver
              advice which invokes the Async processing to take the work off the thread
              that is committing.

              AsyncTransactionObserver which does the opposite would not be as useful
              since you have a race with the commit() on the main thread, but you get the

              • 4. Re: TreeCacheAop object event listener
                Adrian Brock Master

                In the dynamic case, you only need to insert the advice, you don't need
                the interface on the front end since you know what wants to addObserver().

                • 5. Re: TreeCacheAop object event listener

                  You are right. I need a FineGrainedObservable with a new Subject and Intecerptor that can send the specfic event (e.g., particular field get/set). But since I am interested in the dynamic case, I won't need Introduction declaration in the xml.

                  I will try it on my cache aop first.



                  • 6. Re: TreeCacheAop object event listener
                    Bill Burke Master


                    instead of writing an observer/observable framework, instead, well-defined pointcuts should be published. Basically, what you do is define the pointcut expressions for each integration point in JBossCache and name them. Then anybody can do anything they want around these named pointcuts. They can write any observer/observable pattern they want.


                    • 7. Re: TreeCacheAop object event listener

                      This is a good suggestion. Is there a way to look up the named pointcuts dynamically?