Issue - 245 - Clarification on repeatEvery

[ws-bpel issues list editor <peter.furniss@choreology.com>]

This issue has been added to the wsbpel issue list with a status of "received". The status will be changed to "open" if a motion to open the issue is proposed and that motion is approved by the TC. A motion could also be proposed to close it without further consideration. Otherwise it will remain as "received".

The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC document, is the most recent version of the document entitled in the "Issues" folder of the WSBPEL TC document list - the next posting as a TC document will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL.

Issue - 245 - Clarification on repeatEvery

Status: received
Date added: 28 Feb 2006
Categories: Specification editing
Date submitted: 27 February 2006
Submitter: Mark Ford
Description: The last sentence of Section 12.5.4.1. reads as follows: 
> The repeatEvery alarm event is created repeatedly each time the duration expires, while the associated scope is active.
It is possible that the execution of an onAlarm's child activity could take longer than the value of its repeatEvery expression. Since concurrent execution of a single onAlarm instance is not permitted (as stated in 12.5.7) then the process would have to queue these onAlarm executions and fire the onAlarm again once it has completed executing.

There are a few possibilities here:

1. Avoid this issue by rescheduling the alarm each time the activity within the onAlarm completes. The drawback is that depending on the activities within the onAlarm it might not truly fire every N seconds (or whatever its expression duration evaluates to).

2. Allow the queuing of the onAlarms and consider the onAlarm active until all of the queued alarms have been dispatched. This will result in the scope waiting for the alarms to get delivered.

3. Allow the queuing of the onAlarms but do not consider the onAlarm active if it has queued alarms. The scope will not wait for the onAlarm to process any queued alarms.

Submitter's proposal: I think option 3 is the right approach.

As such, I propose the following lines (in bold) be added to section 12.5.4.1:

12.5.4.1. ALARM EVENTS

The counting of time for an alarm event with a duration starts when the enclosing event handler is activated. An alarm event goes off when the specified time or duration has been reached. Except for the repeatEvery alarm, an alarm event is carried out at most once while the corresponding scope is active; the event is disabled for the rest of the activity of the corresponding scope after it has occurred and the specified processing has been carried out. The repeatEvery alarm event is created repeatedly each time the duration expires, while the associated scope is active. Only a single instance of a repeatEvery alarm is allowed to fire at one time. In the event that the execution of the alarm takes longer than the specified repeatEvery duration, then the scope will queue these alarms and dispatch them immediately upon completion of the onAlarm's current execution. In the event that the scope has completed its normal execution then the scope will only wait for the currently dispatched alarm to complete and not for any queued repeatEvery alarms.

Changes: 28 Feb 2006 - new issue

---

To comment on this issue (including whether it should be accepted), please follow-up to this announcement on the wsbpel@lists.oasis-open.org list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - 245 - [anything]" or is a reply to such a message. If you want to formally propose a resolution to an open issue, please start the subject line "Issue - 245 - Proposed resolution", without any Re: or similar.

To add a new issue, see the issues procedures document (but the address for new issue submission is the sender of this announcement).