[JBoss jBPM] - Re: new rows inserted into jbpm tables every time jboss is s
by tester74
It looks like it is a jbpm feature and goes by versioning mechanism. I see the following in the jbpm jpdl reference at
http://www.jboss.com/products/jbpm/docs/jpdl
How do I avoid versioning and keep the same process definition unless something has really changed in the process definition file? Any help deeply appreciated. IN my scenario, the server may be brought up and down multiple times and every time this is done, I will lose all contexts from previous actions, unless I store the processDefinition Id in a user database.
-----------
Versioning mechanism
Basically, the versioning mechanism of jBpm comes down to the following principles :
* every time a process archive is deployed, a new process definition is created in the jBpm database
* at deployment, jBpm assigns a version number to the process definition. Process archives are considered the same when the name of the process is the same. To assign the version number, jBpm takes 1 + (the highest version number of the current process definitions with the same name). Or 1 if it is the first version. From the jBpm-API you can ask for the latest process definition with a given name.
* ones a process instance (=one process execution) is started in a given definition, the process instance will keep on executing within the same definition till its finished.
* this way every process can start in the latest definition and keeps on running in the same definition for its complete lifetime.
* note that in jBpm it is even possible to version the programming logic associated with a process. By including the classes in the process archive, jBpm will separate the classes per process definition.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131457#4131457
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131457
18 years, 2 months
[JBoss jBPM] - Re: Token.signal() ---> 2 tokens?
by kukeltje
anonymous wrote : Please, can you clarify what the difference is between 'the states' and 'the state nodes'?
I probably should have said 'wait-states' and state-nodes. task-nodes are generally also wait-states, and the generic 'node' can be made into a wait state or auto-transitioning node by adding java code to it
anonymous wrote : If jBPM is no longer capable/suitable, then I need to find that out pretty soon! No, not much has changed. Maybe the behaviour around this signalling of the root-token (or any subtoken that arrives at a fork) has.
Your 'solution' seems ok, but I wonder what the advantage is in doing it this way. You can use 'node' instead of 'state' which can auto-transition if finished. No need to signal at all then. Might have some disadvantages also, but probably less if you use them where applicable and async states where possible.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131444#4131444
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131444
18 years, 2 months