Hi,
The "atomic" term in the original spec text has its own meaning already:
"An
important characteristic of assignment in
BPEL4WS is that assignment activities are atomic.
If there is any fault during the execution of an assignment activity,
the destination variables are left unchanged as they were at the start
of the
activity. This applies regardless of the number of assignment elements
within
the overall assignment activity."
I read the text as: when there are multiple <copy> within one
<assign>, the result of multiple <copy> is atomic.
I would suggest the new text to look like:
"An
important characteristic of assignment in
BPEL4WS is that assignment activities are atomic.
If there is any fault during the execution of an assignment activity,
the destination variables are left unchanged as they were at the start
of the
activity. This applies regardless of the number of <copy>
elements within
the overall assignment activity. Also,
the assign activity MUST be executed as if, for the duration of its
execution, it was the only activity in the process being executed. The
mechanisms used to implement the previous requirement are
implementation dependent. "
If one wants to remove atomicity completely, then I believe it requires
filing of another BPEL issue.
Does it make sense?
Thanks!
Regards,
Alex Yiu
Assaf Arkin wrote:
I would
prefer if we not use the term atomic at all, just describe the expected
behavior. It provides enough precision without any confusion.
Assaf
Alex Yiu wrote:
Hi, Yaron and others,
For Issue 166,
Yaron's change of text:
"The assign activity is treated as if it were atomic. *This means that*
the assign activity MUST be executed as if, for the duration of its
execution, it was the only activity in the process being executed. The
mechanisms used to implement the previous requirement are
implementation dependent. "
This text essentially implies: the "atomic" term in the text is NOT the
"atomic" term in ACID.
The "atomic" term is more similar to "atomic" operation from typical
CPU machine instructions or traditional / transaction-unaware
programming language viewpoint.
If we change the text to become:
"The assign activity is treated as if it were atomic. *Also,* the
assign activity MUST be executed as if, for the duration of its
execution, it was the only activity in the process being executed. The
mechanisms used to implement the previous requirement are
implementation dependent. "
Then the implication is gone.
What do you guys think?
I know it's a kind of terminology nitpicking issue.
I just want to make sure the edit group make a conscious decision here.
Thanks!
Regards,
Alex Yiu
Yaron Y. Goland wrote:
For issue 137 I completely rewrote section
8.1 to make it a lot more concrete and illustrative (the existing text
never even used the word property) and then deleted a few sentences
from 8.2 and added in some normative language around refreshing
property values and assigning to non-Lvalues.
For issue 166 the language I put into 14.3 is:
The assign activity is treated as if it were atomic. This means that
the assign activity MUST be executed as if, for the duration of its
execution, it was the only activity in the process being executed. The
mechanisms used to implement the previous requirement are
implementation dependent.
For 175 it wasn't immediately clear to me which section was best but 3
seemed the least awful. Here is the language I inserted:
While WS-BPEL attempts to provide as much compatibility with WSDL 1.1
as possible there are two areas where such compatibility has proven
impossible. One area, discussed later in this document, is in fault
naming. The other area is in support for overloaded operation names in
WSDL portTypes. A BPEL processor MUST reject any WSDL portType
definition that includes overloaded operation names. This restriction
was deemed appropriate as overloaded operations are rare, they are
actually banned in the WS-I Basic Profile and supporting them was felt
to introduce more complexity than benefit.
For 178 I inserted the following language into section 13:
All handlers on a scope are lexically subordinate to the scope and so
can access all variables, partnerLinks and correlation sets defined on
the scope and its linear ancestors subject to any restrictions unique
to the handler type specified elsewhere in this document.
Thanks,
Yaron
|