I actually included it because it may allow you to remove some of your custom wiring of the messages into the process.
You are correct that most of the time a race condition will trigger a FlowableOptimisticException but clearly something is getting around the locking we do have. I would expect a slow database connection to lead to connection timeouts not a deadlock, though I suppose it increase the time a transaction takes and also time the application is vulnerable to this occurring.
I’d look at the following:
- Foreign keys without indexes (there are scripts out there to help find them)
- Prevent running on the same execution id at the same time somehow.
- Perhaps try an upgrade to 6.4.2 to see if it might solve the problem
Another upcoming feature that may help once 6.5.0 is released is Logging Sessions:
Shameless plug: Flowable does offer support and consultancy services