All:
One rather significant issue I've encountered with jBPM (currently using 3.1.2) is the limitations on the length of ContextInstance variables able to be persisted when a process instance is saved. I understand that there are several ways to deal with this:
- truncate the variable value
- use transient variables
- change the hibernate mappings and the database schema
However, these options have real weaknesses to them. First, truncation amounts to data loss. Second, transient variables also cause data loss, and effective generalizations of state handling may be indiscriminate about which state is made transient (effectively making generalization a bad move). Third, hibernate mapping and database schema changes are a branch from the vanilla product releases, adding migration work and potential issues to jBPM version upgrades.
I therefore have 2 questions:
1. What strategies are others using for variable persistence in lieu of these limitations?
2. Is this solved in the current release of jBPM (3.1.3) address this?
3. Is there any hope for a unified model of persistence in jBPM which will accommodate variables of all lengths (like flushing all variables to an XML document, which is then persisted to a CLOB)? To my knowledge, there is no present means to do direct querying against instance variables, and so the queryability of the stored XML document would not be an issue. It would be of great benefit to alleviate the need to address every process for variable issues in development.
Thoughts? Is this not an intended direction or issue that is being dealt with? Thanks...even responses to the negative are helpful, as I have to solve this issue for my organization.
Cheers,
Brad
