cancel
Showing results for 
Search instead for 
Did you mean: 

Using non-persistent variables in workflow execution

aglaser
Champ in-the-making
Champ in-the-making
Hi,
I have a workflow which has some wait points (receive tasks). I resume the workflow calling:

  RuntimeService.signal(String executionId, Map<String, Object> processVariables);

As a process variable I pass some input data and after the method returns I like to get back the same variable calling:

  RuntimeService.getVariables(String executionId);

Activiti seams to persist always all variables. For my case this is not neccessary - and not just a performance issue but also in case of serialized Java objects an update problem if those objects are saved in the DB. I have not found a way to mark a variable as non-persistent but an old topic which has been answered as: "not implemented yet".

So, do I have missed something in the documentation or is Activiti still not supporting non-persistent variables?
If this is not support is this feature plannend for a specific version of Activiti?

Of course I can use something like a ThreadLocal but I don't like this approach. It is implicit parameter passing.

I am open for every input/idea.
Thanx, Andreas
4 REPLIES 4

frederikherema1
Star Contributor
Star Contributor
You got it right, this is not yet implemented in activiti. The only "clean-ish" workaround I could think of is to create a single variable (extends hash map or something) that holds all variables you need to keep in-memory.

Make it serializable but override the writeObject and write basically nothing. This way, the "cached value" of the variable will still be your full pojo/hashmap, but serializing/deserializing is *almost* free. Also only one variable-instance is stored compared to the N number of variables stored before.

This is a bit fishy, I agree. Another option is to implement this in the engine and contribute it Smiley Wink

aglaser
Champ in-the-making
Champ in-the-making
Hi,

thanx for your reply.
I will play around a little bit with the idea of using a persistent container and transient key-value-pairs in it. This is better than using a ThreadLocal approach. But still it has the character of an in-out parameter for the service I call from the workflow. But at least it is visible on the service method and the caller must be aware of this.

Nevertheless the best thing would be to have variables which are marked as non-persistent. Maybe an annotation which says Activiti to not persist the variable…..

Sorry, but right now I have absolutly no idea how the Activiti code works and how are the concepts behind the workflow context and variables. Maybe I will find some time to dive in deeper in the Activiti code and be able to create a contribution. At the moment time is short - as always 😞


Greets,
Andreas

meyerd
Champ on-the-rise
Champ on-the-rise
Couldn't you use @RequestScoped Beans in Spring or CDI?

aglaser
Champ in-the-making
Champ in-the-making
Couldn't you use @RequestScoped Beans in Spring or CDI?

I have a Spring based application running in a Tomcat. Incoming calls are not HTTP but JMS. It's a backend server. Playing around with different scopes is nice too but I don't believe this is a good solution.
I like the idea of having a small wrapper/container around the parameter which holds the parameter in a transient field. Activiti can persist the wrapper but the real parameter is not persisted.

But thanx for your idea. It's always good to think in different ways. Sometimes the best solution is around the corner but you never look there…