Proposal: RuntimeService.setProcessDefinitionVersion(pi, pd)

[falko_menge]

We at camunda would like to introduce a method, which changes the process definition version of an existing process instance, to the runtime service.
This method will not perform any migration magic and simply set the process definition version in the database, assuming that the user knows, what he or she is doing.
Of course, this will be carefully documented so that the users know the risks of the operation.

Do you guys have any concerns with such a feature or can we continue with providing an implementation for you to review?

[trademak]

Hi,

This would only be useful for simple migrations right? The new process definition must have the exact same activity id to make it still run.
In addition, if there are still process instances running a transaction, what would you do with those process instances?

Best regards,

[bernd_ruecker]

Hi Tijs.

What do you mean with "running a transaction"? Currently some active thread is working? Then this would be a case for optimistic locking, meaning either the version update or the "real work" wins. Like any other race condition we could have (with e.g. canceling a process instance).

Yeah, this is about a simple upgrade, we need exactly the same activity ids. Maybe at least a consistence check would be a nice feature, but no special magic planned for e.g. activity migration (like we had it in jBPM 3).

Currently the decision is either to implement it in our own monitoring tool or to add it to the Activiti codebase. There I still see 2 possibilites: "Just" implement a Command without exposing it in the public API or even exposing it.

Personally I am fine with all options 🙂

Cheers
Bernd

[trademak]

Hi Bernd,

Right. I would go for the "Just" implement a command without exposing it in the public API approach.

Best regards,

[meyerd]

If there is "just" such a command, we should make sure that there is a testcase to ensure that it will be not broken by internal refactoring without someone noticing immediately.

[falko_menge]

If there is "just" such a command, we should make sure that there is a testcase to ensure that it will be not broken by internal refactoring without someone noticing immediately.

Of course,  the command will be developed test-driven.

[falko_menge]

I added a first version of the command in http://fisheye.codehaus.org/changelog/activiti/?cs=3079
Currently, it needs a process definition id. Next, I'm going to make it work with only a version number.

[falko_menge]

Next, I'm going to make it work with only a version number.

Committed in: http://fisheye.codehaus.org/changelog/activiti/?cs=3080

[rvi]

Hi,

Is it possible to make this service public ?  ( of course with warnings on the limitations of the migration : same activity ids/type, same branches..)

Simple process migration is one of our needs. We plan to use Activiti for service/message orchestration, with camel integration. and it seems easier to keep processes "migratable" than to handle several process versions with the same java/camel code, since it's not possible to have two versions of code running for each process version.

thanks
Richard

[falko_menge]

Hi Richard,

Is it possible to make this service public ?  ( of course with warnings on the limitations of the migration : same activity ids/type, same branches..)

We don't want to expose this feature in the public API, because we want to ensure that the people, who use it, know what they are doing.
However, you can still start the command like this:

((ProcessEngineImpl) processEngine).getProcessEngineConfiguration().getCommandExecutorTxRequired().execute(new SetProcessDefinitionVersionCmd(…))
But let me quote the warning from the documentation of the command:

Warning:
This Command will NOT perform any migration magic and simply set the process definition version in the database, assuming that the user knows, what he or she is doing.

This is only useful for simple migrations. The new process definition MUST have the exact same activity id to make it still run.

Furthermore, activities referenced by sub-executions and jobs that belong to the process instance MUST exist in the new process definition version.

If the process instance is not currently waiting but actively running, then this would be a case for optimistic locking, meaning either the version update or the "real work" wins, i.e., this is a race condition.

[…]it's not possible to have two versions of code running for each process version.

One approach, you can also think about, is to use an environment with strong class loader isolation, e.g., an application server or OSGi container, and add a version number to the process definition key. This way you can run multiple versions of a process definition and the code that belongs to it in parallel. The camunda fox Community Edition allows that, too.

Cheers,
Falko