7 Replies Latest reply on Aug 23, 2007 5:16 AM by mvaldes

    executionMap

    tom.baeyens

      i made some extra docs with executionMap that explains how this only serves as a lazy initialized cache.

      there is still a TODO for the initialization

      in case someone wants to finish it, please post a message here before you start on it.

      also the null pointer checks need to be added in the rest of the execution class

        • 1. Re: executionMap

          I would propose something like this:

          public Execution getExecution(String name) {
          if ((executionsMap==null))
          executionsMap = new HashMap<String, Execution>();

          if (executionsMap.get(name)==null && executions!=null)
          {
          for(Execution exec: executions)
          if (exec.getName()!=null && exec.getName().equals(name))
          {
          executionsMap.put(name, exec);
          return (exec);
          }
          }
          return (executionsMap!=null ? executionsMap.get(name) : null);
          }

          public Execution removeExecution(Execution execution) {
          checkUnlocked();
          if (execution!=null && executions.contains(execution))
          {
          executions.remove(execution);
          if (executionsMap.containsValue(execution))
          executionsMap.remove(execution.name);
          return this;
          }
          return null;
          }

          public Execution removeExecution(String name) {
          Execution exec = this.getExecution(name);
          if (exec!=null)
          {
          executions.remove(exec);
          executionsMap.remove(name);
          return this;
          }
          else
          return null;
          }


          public void removeExecutions() {
          executions.clear();
          executionsMap.clear();
          }

          regards,
          Miguel Valdes

          • 2. Re: executionMap
            tom.baeyens

            in your proposal, getExecution(String name) leaves executionMap in an inconsistent state.

            it should either be null or it should be fully initialized

            also the removes should contain null pointer checks (those i added already)

            best is to start with some tests. tests that add and remove in all kinds of combinations starting very simple. and then checking of all the executions getter methods return the expected result.

            also serialization and deserialization of an execution that has a fully initialized executions map. should be checked in a test

            • 3. Re: executionMap

              Looking into the current implementation (under ExecutionImpl.java file) I noticed that the executionMap attribute is cleaned when a new child execution is created and is initialized with executions values when calling the getExecution method.

              This attribute is also cleaned when a child execution is removed.

              I'm still in thinking that the code I propose (see previous post) wouldb be more performant:

              - An execution is added to both executionMap and executions attributes when creating a new childExecution
              - This execution element is removed from both executions and executionMap when calling the removed method

              and
              - getExecution method (by name) looks first to the executionMap and only to executions if the element doesn't exist (in this case this execution is added into executionMap).

              I was playing with some unit tests with this implementation (including serialization/deserialization operations) and I think is working.
              For sure in some situations, i.e after a serialization/deserialization of the ExecutionImpl class, executionMap is empty but its going to be updated step by step when calling the getExecution method.

              thoughts?

              regards,
              Miguel Valdes

              • 4. Re: executionMap
                tom.baeyens

                executions will not often (ever?) be looked up by name.

                setting the executionMap to null has less memory footprint.

                but it's not a big deal, imo.

                all performance thinking should be spend on db persistence. save 1 roundtrip to the db and you can create populate and play with 50 hashmaps still saving time.

                e.g. if we configure process definitions in the cache as read only, that gives us the best runtime performance. but how then do we update or delete a process definition in case we must do it. we probably will need a separate persistence configuration for that. but how do we manage that ?

                • 5. Re: executionMap

                   

                  "tom.baeyens@jboss.com" wrote:
                  executions will not often (ever?) be looked up by name.

                  setting the executionMap to null has less memory footprint.

                  but it's not a big deal, imo.

                  all performance thinking should be spend on db persistence. save 1 roundtrip to the db and you can create populate and play with 50 hashmaps still saving time.


                  Indeed but the point was why my code proposition left the executionsMap attribute in a inconsistent state ? :-)

                  "tom.baeyens@jboss.com" wrote:

                  e.g. if we configure process definitions in the cache as read only, that gives us the best runtime performance. but how then do we update or delete a process definition in case we must do it. we probably will need a separate persistence configuration for that. but how do we manage that ?


                  In Bonita I implemented my own application cache for process definitions. This cache was initialized when the first instance of a process definition was created and so then used by others instances during the execution.
                  When a process definition changes we just update the cache.

                  regards,
                  Miguel Valdes

                  • 6. Re: executionMap
                    tom.baeyens

                     

                    In Bonita I implemented my own application cache for process definitions. This cache was initialized when the first instance of a process definition was created and so then used by others instances during the execution.
                    When a process definition changes we just update the cache.


                    yes that could be another option. but then we need to have a way on how to bind the process definition objects in the application cache to the runtime execution data when it gets loaded.

                    but we must be sure that we don't want much configuration options. cause otherwise, we will be building a full cache impl...

                    • 7. Re: executionMap

                       

                      "tom.baeyens@jboss.com wrote:

                      yes that could be another option. but then we need to have a way on how to bind the process definition objects in the application cache to the runtime execution data when it gets loaded.


                      Yes I remember some bad experiences when I applied this cache to Bonita in v2. An extensive refactoring was required for execution classes :-)

                      regards,
                      Miguel Valdes