-
1. Re: executionMap
mvaldes Aug 3, 2007 9:41 AM (in response to tom.baeyens)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 Aug 3, 2007 11:14 AM (in response to 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
mvaldes Aug 22, 2007 3:19 AM (in response to tom.baeyens)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 Aug 22, 2007 3:27 AM (in response to 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
mvaldes Aug 22, 2007 10:48 AM (in response to tom.baeyens)"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 Aug 22, 2007 11:01 AM (in response to 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
mvaldes Aug 23, 2007 5:16 AM (in response to tom.baeyens)"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