Persistance race condition

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

blezek

Hi,

  We are using Activiti in perhaps a very different way and running into some problems.  Our app is distributed across multiple servers, connected by a message queue.  A single server runs an embedded version of Activiti.  When the workflows hit a particular custom task, we post a message to the message queue inside a subclass of TaskActivityBehavior (but the problem shows up using JavaDelegate as well).  Another server picks up the message and does some processing and sets a variable on the workflow like this:

    runtimeService.setVariable(request.executionId, "SeriesObject", seriesObject);
‍‍

Depending on the timing, the call to setVariable may throw an exception because the workflow (running on a different machine), may not have persisted the execution to the database yet.  Sometimes it works just fine.

My question: how should we handle this problem?  Can we/should we

1. force the workflow to persist before we send the message to the message queue?

2. use Activiti's transaction manager to make sure the message is sent only after the workflow is persisted?

3. have a callback to know when Activiti persists the execution?

4. delay the send until the workflow is persisted? (Don't like this option, would be a spin lock)

Thanks!
-dan

ronald_van_kuij

Personally I think two is the best. It is the most natural way and the way transactios are meant to be used.