[jbpm-dev] [Design of JBoss jBPM] - Re: first cut of the new history

[tom.baeyens@jboss.com]

the bigger picture is this:

in jbpm 3 we have a flat log table.  

biggest problem with that is that it contains references to the runtime data (tokens and process instances).  because of that reason, the runtime data cannot be deleted and it keeps growing.

now in jbpm 4, we'll have a history schema that does not reference the runtime data (it can reference process definition data as that data remains in the db).  as a result, now process instance data is deleted once it is no longer needed.  e.g. executions and variables get deleted when they go out of scope.  and the full process instance is deleted when it ends.

the runtime data tables stay clean and healthy this way.  the reporting and other monitoring is done on a separate set of tables.  so this also makes the whole system more performant.  

so in jbpm 4 we will not have a flat log file, but a fully fledged schema that contains the history information of what happened when in the process executions.

so an extra advantage is that the history schema is designed to be easy queryable.  it can contain some de-normalized duplications of information.  (e.g. startTime, endTime and duration fields).

internally, the architecture remains almost the same: runtime execution still generates history events (previously called processlogs).  there is a pluggable history session that captures these history events.  and the rest is described above.

does this help ?

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209890#4209890

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209890