nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

ActivitiOptimisticLockingException: SignalEventSubscriptionEntity

capacman

Hi,

In one of my tests i get

"Exception in thread "pool-2-thread-3" org.activiti.engine.ActivitiOptimisticLockingException: SignalEventSubscriptionEntity[28628] was updated by another transaction concurrently"

After this error it seems to be one of the intermediate timers is not fired.

Find more posts tagged with

Comments

jbarrez

Do you have multiple job executors running (or multiple engines on same database)

If so, this error is expected, as mutliple threads are competing for the same resource.

capacman

Actually i have one job executor in one engine. But what i was triying to do is create a pool of 100 threads and each thread simulating customer behavior by generating signals randomly. Process definition includes an intermediate timer and when it is fired it checks whether customer met some condition then process instance ends. The odd thing whenever i see this error it seems to be this intermediate timer path is not completed. I think if my simulation thread starts to change some variable and at the same time job executor thread try to change something(this is actually exactly the same situation that u describe above i think) but simulation thread finishes first,then job executor thread get this error but never try again and led to sitiation of my process instance not ends because timer path is the only path that can end my process instance. Am i correct? Is it possible?

jbarrez

If you have multiple threads signalling randomly then this exception is expected. One of the thread wins, the other loses, it is as simple as that.

But it should end your process instances, since one threads 'wins'. Do you see jobs in your database after the thread have run? Jobs that have a retry > 3 or an exception set?