3 Replies Latest reply on Oct 5, 2007 9:31 AM by tom.baeyens

    application level cache

    tom.baeyens

       

      "Miguel Valdes Faura" wrote:
      We see different issues with using application level cache (as you proposed in your email yesterday):

      - Updates: even if this cache is intended for process definition (so updates will no often occurs), there is still a need (specially in a distributed environment) to update this cache. And so, the mecanism you proposed (periodic check) will be hard to implement compared with traditional mecanism provided by cache implementations.

      - Additional work: an extra work is required to implement this cache. User types must be defined and so new classes must be developed and configured.

      After a first prototype made by Guillaume, the use of second level cache is working fine. And this is independent of the JPA vs Hibernate choice.

      The only drawback with this approach is that in some situations (i.e in JPA with Hibernate or in Hibernate standalone version) cached objects are re-created each time. In others JPA providers (i.e Toplink) we have the choice to either re-create or not the objets.

      Anyway, we think that objects re-creation in memory is not really a big issue compared to manually handle the process definition cache.


        • 1. Re: application level cache
          tom.baeyens

          one correction: if we use second level cache, we still will need to implement the caching of the wired objects. rebuilding them each time is not an option for me.

          all in all, this is a close call for me.

          let's start with using the 2nd level cache and an application cache for classloaders and wired objects. later, we should not forget to add a mechanism to clean those caches from a cluster in case a process needs to be updated (which is different from a re-deployment). i currently don't see any other mechanism then using appserver specific clustering features for that.

          • 2. Re: application level cache
            porcherg

             

            "tom.baeyens@jboss.com" wrote:
            one correction: if we use second level cache, we still will need to implement the caching of the wired objects. rebuilding them each time is not an option for me.


            as far as I understand, wired objects are associated with an environment. If an object is described in a block context, it should be recreated for each thread (so no cache for these objects).

            For objects described in the application context, they may need to be persisted, as they contain useful information about the state of the engine. For example, in the BPEL extension, the publisher has the list of deployed process. If the publisher is not persisted and is recreated from the descriptor, these informations will be lost (this is maybe another discussion)

            What do you think needs to be persisted in an environment and which wired objects need to be cached ?

            regards,
            Guillaume

            • 3. Re: application level cache
              tom.baeyens

              if you want data from the db to be available in the environment, you have to implement a context for it. e.g. a BpelEngineContext. That context will make available the persistent state to the environment.

              contexts are a way to expose things in the environment. but at no time should the environment/context infrastructure itself be used to persist things. that should be decoupled.