OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] State of variables following bpel:invalidVariables fault


Title: State of variables following bpel:invalidVariables fault

Mark,

The way that I read is: yes the "bpel:invalidVariables" fault (just like any fault happens during <assign>, e.g. selectionFailure ) will revert variables back to original state before the execution of <assign>.

The current text is relatively clear to me. If other people think the text is still unclear, please feel free to voice suggested clarification text.


Regards,
Alex Yiu


Mark Ford wrote:

The following two paragraphs are from Section 8.4:

--- begin spec text ---
If there is any fault during the execution of an assignment activity the destination variables MUST be left unchanged, as they were at the start of the activity (as if the assign activity were atomic). This applies regardless of the number of assignment elements within the overall assignment activity.

If the "validate" part of the assign activity fails, that is, one of the variables is invalid against its correponding XML definition, a standard fault of "bpel:invalidVariables" fault MUST be thrown.

--- end spec text ---

Does this fault cause the variables to revert back to their original state? My first thought was that it wouldn't since the first paragraph was probably written with the copy operations in mind, however, it could be read either way.

Is this an issue or is it an action item? Please advise.

Thanks.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]