5 Replies Latest reply on Apr 23, 2003 2:38 PM by Bela Ban

    Anybody feel like reconstructing?

    Sanne de Novice

      So I've been to the Jboss course ('... JBoss is simple ...'), I've read the cache spec, put out some thoughts on how things could come together, but I'm definitely lost now, especially after the ACID AOP post on the AOP forum.

      What should end up in the cache, and when? How does the cache relate to locking, and to persistence?

      After a client has obtained a reference (CMP scenario), every invocation is transformed into an invocation object, containing tx info, object type info, object pk info, method name, and method arguments.

      When the invocation object arrives on the server it is routed to and MBean through a set of interceptors.

      The security interceptor looks if there are any security constraints attached to the method call.

      The tx interceptor checks the tx requirements for the call: required, requires new, not supported, supports etc.

      Then the lock interceptors determines whether the tx may call an object, in other words, does the invocation object have a tx that holds the lock.

      O.k. now the actual state of the called object must be associated with the call.

      (the 3.x entityCreationInterceptor, the EJB already exists)

      This is where the cache comes up. If the EJB is not in the cache, then the persistent manager has to associated an instance from the pool with the data from the db, insert it in the cache, and return the the object.

      If the instance is already in the cache, then the object doesn't have to be created from the pool and be assigned a state, that's what caches are for.

      When an object is removed from cache the cache also schedules the passivation. (EntityInstanceCache.java, AbstractInstanceCache.java)

      To construct the state using the ACID AOP, not only a cache instance needs to be obtained, but also the recorded changes need to be applied.

      Anybody feel like reconstructing?

      Sanne

        • 1. Re: Anybody feel like reconstructing?
          Sanne de Novice


          > That the discussion on the forum/in my head from my
          > side was to much centered at the Cache JSR, while the
          > cache also has close links with persistence.

          Yes. My first prio is a transactional cache with mode {transient, repl-async and repl-sync}.

          The second task is to use this cache, and here the main use case is caching of entity beans. I have been meeting with Jeremy to get the cache integrated with the persistence engine.

          The 3rd task is to use AOP to know when an object has been changed, and then replicate the changes.


          All of those 3 tasks are orthogonal, and can be (and are !) worked on in parallel.

          Task #3 has not yet been started. What I have in mind here was described in one of my prev postings (about the status inquiry by Marc).

          Actually, I'll post it here as a separate task.

          Bela

          • 2. Re: Anybody feel like reconstructing?
            marc fleury Master

            > So I've been to the Jboss course ('... JBoss is
            > simple ...')

            yep that is what the course is there for.

            > What should end up in the cache, and when? How does
            > the cache relate to locking, and to persistence?

            good question. Just did the same in Paris :) Ok so basically ending up in cache just means putting a reference with an object tree under a key. Period. that is the put. There is no notion of "state validity" or notion of locking at this point. Just a map where you can lookup and replicate in a cluster.

            > After a client has obtained a reference (CMP
            > scenario), every invocation is transformed into an
            > invocation object, containing tx info, object type
            > info, object pk info, method name, and method
            > arguments.

            In the case you are using DP yes. As you correctly identify this is the CMP case we teach you in the class. In the case of pure AOP 4.0 there may not be an EJB... but I digress... go on.

            > When the invocation object arrives on the server it
            > is routed to and MBean through a set of
            > interceptors.

            true, for EJB. For AOP there is a POJO no MBean.

            > The security interceptor looks if there are any
            > security constraints attached to the method call.

            yep :) you got the class.

            > The tx interceptor checks the tx requirements for the
            > call: required, requires new, not supported, supports
            > etc.

            Stop giving all the goodies ;)

            > O.k. now the actual state of the called object must
            > be associated with the call.

            negative.

            > This is where the cache comes up. If the EJB is not
            > in the cache, then the persistent manager has to

            negative, negative.

            > associated an instance from the pool with the data
            > from the db, insert it in the cache, and return the
            > the object.

            were you sleeping on tuesday morning? who was your teacher? we are talking CMP2.0 meaning full control of get/set operations (we know when you need state, it is when you call get). It is also where AOP comes in full force. We instrument get/set just like we did CMP2.0. See?

            >
            > To construct the state using the ACID AOP, not only a
            > cache instance needs to be obtained, but also the
            > recorded changes need to be applied.
            >
            > Anybody feel like reconstructing?

            ok the key is to think with CMP2.0, you correctly identified all the points in the class but then put them together and you will see that state recording is an AOP feature. Yes? see the AOP forum for early discussion with Bela and how we instrrument references to dostate change recording within transactions.

            >
            > Sanne

            Keep your sanity you are almost there.

            • 3. Re: Anybody feel like reconstructing?
              Sanne de Novice

              Hi Marc,

              Thanks for giving such long reply. These days I'm back to study-ing the internals of JBoss again, be it 3.0.6.

              The ranting above was more to elicit a vivid discussion on this topic since a lot more is involved in JBoss Cache then the Cache JSR; well you chipped in.
              Didn't work well up till now.

              Regards,

              Sanne

              • 4. Re: Anybody feel like reconstructing?
                Bela Ban Master


                > The ranting above was more to elicit a vivid
                > discussion on this topic since a lot more is involved
                > in JBoss Cache then the Cache JSR

                meaning ?

                Bela

                • 5. Re: Anybody feel like reconstructing?
                  Bela Ban Master


                  > That the discussion on the forum/in my head from my
                  > side was to much centered at the Cache JSR, while the
                  > cache also has close links with persistence.

                  Yes. My first prio is a transactional cache with mode {transient, repl-async and repl-sync}.

                  The second task is to use this cache, and here the main use case is caching of entity beans. I have been meeting with Jeremy to get the cache integrated with the persistence engine.

                  The 3rd task is to use AOP to know when an object has been changed, and then replicate the changes.


                  All of those 3 tasks are orthogonal, and can be (and are !) worked on in parallel.

                  Task #3 has not yet been started. What I have in mind here was described in one of my prev postings (about the status inquiry by Marc).

                  Actually, I'll post it here as a separate task.

                  Bela