transitions as wait states

[tom.baeyens]

In petri nets and the way that transitions are interpreted, transitions can take a long time to fire. E.g. I read once an example where a user task was modelled as a transition.

Also, I think it makes sense for an analyst to model an original state (e.g. 'ugly') as a node and a desired state (e.g. 'good-looking') as another node and have a transition inbetween.

In both cases, time can elapse during the transition. So start taking a transition doesn't necessarily have to be done in the same transaction as arriving in the destination node.

So we could/should? split the current TakeTransition atomic operation into 2 separate atomic operations.

For the persistence, this isn't really difficult. The ExecutionImpl already has a transition memberfield to indicate the current transition. That field just has to be made persistable.

So that is why i want to evaluate if having wait states as transitions can be build on the pvm.

On the one hand, I see this as a real limitation. Cause not having this feature means that the graphical process model is *forced* to have a node if a transition takes a long time (read: needs a transaction commit and an external trigger starting a new transaction). This limits the analysts freedom. Or in other words, it makes the developer's job harder to translate the analyst process model into an executable process model.

But on the other hand, practice has shown in jPDL that the limitation of requiring a node for wait states didn't give much problems. So if it turns out to be too hard, we could skip it.

[mvaldes]

I agree that could be useful. I'm thinking on workflow uses cases in which a graph is shown based on states rather than activities (i.e a document validation process in which the transitions between two document states is a waitstate: validate a document).

On the other side I don't see that as a priority right now but is good to keep that in mind.

regards,
Miguel Valdes

[tom.baeyens]

i think we do need to work this out cause it can have big consequences in the engine. i've been reflecting a bit on this and there were a few implications.

mainly we need an interface (probably we can leverage the Condition interface, needed for guard conditions) that indicates wether the transition needs to continue automatically or wether it is a wait state that needs an external trigger.

i think it's best to work it out only on the pvm level with one or two test cases. then we can leave the rest of the bells and wistles for later.

[tom.baeyens]

it was ok. transitions as wait states are implemented