How can I prevent a process execution is run multiple times?

[mamue]

Hi,

we provide a list of open tasks to our users.
The same user can display this list in different web sessions.
He or she may proceed the same task from different sessions at nearly the same time.
This results in multiple calls to taskService.complete(taskId) with the same taskId.
I expect that the second and all further calls of taskService.complete(taskd) fail, but they do not - at least if the first call is still be executed.

How can I prevent multiple executions of the same task?

Kind regards,
Markus Mueller

[mamue]

Hi Jorg,

I agree with your motivation (simplicity) but I don't understand your reasoning.

Our solution must be simple to the user.
It should be as simple as possible for programmers of Activiti.

I admit that my database based proposal means some implementation work.
And I also admit that my proposal above may be simplified.
(Details will follow - above I described what we had implemented some years ago.)

I don't agree that it is possible that we use Hazelcast in our application to provide locking.
There might be several distributed installations of our application in the same LAN.
Hazelcast uses IP multicast by default. Therefore the installations would interfere and conflict.
To avoid this we (respectively our users) must configure TCP/IP.
This is the opposite of simplicity. We want to spare our users this complexity.

The database based proposal is very simple to the user:
He does not see it!
The only thing that he must do is to identify the deployment:
- singlethreaded application (–> no locking)
- multithreaded application (–> Java based locking)
- multiple JVMs e.g. running on different machines (–> Database based locking)
It is sufficient to configure this once e.g. when Activiti is started.
There is no need to extend process definitions as I proposed in http://forums.activiti.org/en/viewtopic.php?f=6&t=4138&p=16209#p16209

But I guess it also depends on the technology that is trusted the most in your organisation,
that's definitely a factor as well. Which is exactly why activiti should not embed this in the core.

You do not need to embed any additional technology in Activiti if database based locking is used.
The needed tool - the database - is already onboard.

Kind regards,
Markus Müller

[heymjo]

I don't agree that it is possible that we use Hazelcast in our application to provide locking.

i never said it was just pointed out that it would be a very simple global lock mechanism.

From what you write it sounds like you're developing a product, and your first users are developers or the infra people installing the product ? Then i can understand your case for having no extra requirements on the infrastructure external to activiti. For our case, where we just deploy 'normal' workflow based applications in our organization this is not a problem, so having solid global locks with 3 lines of code is a no-brainer.

[mamue]

From what you write it sounds like you're developing a product, and your first users are developers or the infra people installing the product ? Then i can understand your case for having no extra requirements on the infrastructure external to activiti.

Yes, that's right, thank you for your response.
We have just detected another basic aspect we must first check before further discussing the need of locking taskService.complete.
And next week I'm out of office.
Have a good time in the meanwhile!  🙂

Kind regards,
Markus Müller

[avalde]

We're running Activiti 5.19 and experience the same situation as described in this thread:
When a user task is completed twice at nearly the same time, the following script task is executed twice. When the next user task is reached, one of the executions run into an optimistic lock exception and is rolled back.

This is a pretty old thread and I wonder if there has been implemented any mechanisms in Activiti to prevent duplicate executions? Database based mutex in order to handle several JVMs.

If not, I'm very interested to hear if anyone has implemented logic using the engine which is prepared for this or has any suggestions as to where we should implement a global lock (interceptor or similar).

[jbarrez]

This is the default behaviour of Activiti. if your script task logic is not transactional, you need to make it either transactional or indeed use locking somehow.