topic Re: Proposal: RuntimeService.setProcessDefinitionVersion(pi, pd) in Alfresco Archive

Proposal: RuntimeService.setProcessDefinitionVersion(pi, pd)

falko_menge — Tue, 15 Nov 2011 13:35:39 GMT

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 o

Re: Proposal: RuntimeService.setProcessDefinitionVersion(pi, pd)

trademak — Wed, 16 Nov 2011 18:38:46 GMT

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,

Re: Proposal: RuntimeService.setProcessDefinitionVersion(pi, pd)

bernd_ruecker — Wed, 16 Nov 2011 19:19:33 GMT

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

Re: Proposal: RuntimeService.setProcessDefinitionVersion(pi, pd)

trademak — Thu, 17 Nov 2011 18:16:06 GMT

Hi Bernd,

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

Best regards,

Re: Proposal: RuntimeService.setProcessDefinitionVersion(pi, pd)

meyerd — Fri, 18 Nov 2011 08:09:26 GMT

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.

Re: Proposal: RuntimeService.setProcessDefinitionVersion(pi, pd)

falko_menge — Fri, 18 Nov 2011 08:42:08 GMT

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.

Re: Proposal: RuntimeService.setProcessDefinitionVersion(pi, pd)

falko_menge — Wed, 23 Nov 2011 14:25:16 GMT

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.

Re: Proposal: RuntimeService.setProcessDefinitionVersion(pi, pd)

falko_menge — Wed, 23 Nov 2011 16:03:22 GMT

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

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

Re: Proposal: RuntimeService.setProcessDefinitionVersion(pi, pd)

rvi — Wed, 11 Apr 2012 09:21:47 GMT

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

Re: Proposal: RuntimeService.setProcessDefinitionVersion(pi, pd)

falko_menge — Wed, 11 Apr 2012 10:07:27 GMT

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

Re: Proposal: RuntimeService.setProcessDefinitionVersion(pi, pd)

rvi — Thu, 12 Apr 2012 07:41:00 GMT

Thanks for reply, I understand your point for keeping it private. I just want to make sure it stays stable and won't be removed or changed without notice.

[…]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.

yes, i've thought about versioning process definition key for process changes that don't support simple migration.
but I don't see exactly how strong class loader isolation can solve the problem for class version: you would need one activiti engine per process version (in the same classloader as process code) ? what about persistence, would you also need one database per engine ?

thanks
Richard