I am currently working on a project that includes flowable as an orchestrator.
We have chosen to use the embedded version (6.4.2), ran with spring boot (2.1.6) on java 8 and an oracle database.
We are facing a bit of an issue with some optimistic locking exceptions in one of our sub processes.
The issue only started to happen in test env (2 nodes, clustered), not in local (1 node, H2 DB) but, from what I’ve gathered from your documentation and my research on the problem, this should not be a part of the problem.
I am looking for advice / a possible solution to this but any tip / useful advice / best practices about flowable integration is welcome as well.
Here’s a sample of the process that causes the issue with a light description of what’s under the hood
The use case :
The Task “Calls” sends a varying number of request to another app that will trigger asynchronous returns.
Every “WaitX” conditional receive task is used to wait on an asynchronous return
These returns include some data that we want to persist in the flowable context (process instance)
The doStuff task uses the “raw” data put in the flowable context by the receive task to properly modify our business object
The error :
An optimistic locking exception, presumably, caused by the way we add this data to the flowable context
The implementation :
We use the method setVariable (with the pid, a unique varname, and a balue) of the runtimeService to add our data to the flowable context
We have this “modifications to the variables of a process instance from outside of the flowable context” use case in other places.
Is it possible that the use of setVariable is the cause of our problem ?
Any advice / best practice to add variables to our process instance in a transaction safe way ?
I’ve had a few ideas :
- Look into variableService and see if variable insertion raises the same type of issue
- Use a Subprocess for the reception and an out variable
- Persist the payload of the asynchronous return in a non-flowable table and fetch it from a flowable task
- Put a local variable from the runtimeService and make the doStuff task synchronous to see if the shared transaction would allow us to retrieve the local var while hopefully avoiding locking
These are either a bit time consuming research-wise or seem to be hacks rather than solutions so I was hoping for a good advice.
I’ve read about asynchronous / exclusive tasks in your documentation, as well as about transaction management but I remain rather new to flowable in general.
It is my understanding that inclusive gateways generate executions for every path and that could prove useful but I haven’t found enough info about this.
If you need any additional info about our understanding / implementation / configuration before diving in, feel free to ask.
I’m bound to keep the business specifics to myself but will happily provide further detail concerning the hows and whys of some of our choices, or code samples (with altered naming).
Thanks in advance,