Text for issue 32

[Sid Askary <saskary@nuperus.com>]

Folks,
Sorry for the delay (email issues).  In thinking about the problem, I wrote the following paragraphs as an additions to the end of section 12.5.1 and 13.6.  (I also have a version of text reflecting thread and CPU, if interested :-)).

Let me know what you think before I check it in.

Thanks,
-Sid.

//section 12.5.1 - Link Semantics

If links are used within event handlers (both message and alarm), they are not permitted to leave the boundary of the event handler within which they are defined.  That is to say, event handlers, when instantiated via events (alarm and messages) execute within their own context (with local copies of variable).  The value of link status is determined by examining the local copy of the "transitionCondition" attribute of the link.

The event handler instantiated as a result of an "alarm" event is treated as having a single execution context (one event handler with one local copy of the variables - including "transitionCondition") capable of executing only one time within the scope in which it occurs.

The message event handler instantiated as a result of a "message" is treated as being capable of having multiple execution contexts (many event handlers, each with a local copy of variables - including "transitionCondition") each capable of executing multiple times within the scope in which they occur.

//END section 12.5.1 - Link Semantics



//section 13.6. Serializable Scopes

Since links can be thought of as providing the additional assertion and concurrency control over a group of activities (in addition to the state maintained within shared variables), for a serializable scope with an event handler, care must be taken to insure their usage does not conflict with the intended outcome of the business process.  This situation can arise in the usage of <flow> activity (containing <links>) within handlers, as handlers themselves can contain activities (see Link Semantics).

//END section 13.6. Serializable Scopes