Sorry, I didn't completly get it. Could you maybe start with the bigger picture first bevore going into the details? I didn't catched the idea yet.
Of should I maybe read a bit of code if its already checked in?
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 ?
Thanks for the clarification. This is a great modification compared to jbpm 3!
This allows to keep the runtime structures nice and tidy and the queries fast :-)
btw, i started wednesday evening and i just finished the first results of that work:
* process instances and activity instances are now recorded
* avg duration per nodes part of the api
* for choice activities like decision, state and tasks, the distribution of how many times each transition is selected can be queried with one api method
queries based on task assignee will also be possible. any good ideas ?
Okay, now I got it. This is indeed a very good improvement! I will try to have a look at the code asap (but cannot yet promise that I will have time :-/)...