ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karthick Sankarachary (JIRA)" <j...@apache.org>
Subject [jira] Updated: (ODE-396) Atomic Scopes And Processes
Date Wed, 12 Nov 2008 21:13:44 GMT

     [ https://issues.apache.org/jira/browse/ODE-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Karthick Sankarachary updated ODE-396:

    Attachment: atomic-scopes-and-processes.txt

This patch delivers the atomic scopes and processes feature.

> Atomic Scopes And Processes
> ---------------------------
>                 Key: ODE-396
>                 URL: https://issues.apache.org/jira/browse/ODE-396
>             Project: ODE
>          Issue Type: New Feature
>          Components: Axis2 Integration, BPEL Compilation/Parsing, BPEL Runtime, JBI Integration
>    Affects Versions: 1.2
>         Environment: platform-independent
>            Reporter: Karthick Sankarachary
>             Fix For: 2.0
>         Attachments: atomic-scopes-and-processes.txt
>   Original Estimate: 504h
>  Remaining Estimate: 504h
> In general, WS-BPEL processes are susceptible to transient errors that stem from faulty
service interactions. Most real-world applications make an attempt to recover gracefully from
such errors by retrying the piece of work that failed, taking care to roll it back first.
If the probability of the error reoccurring is low, then chances are that the application
will be able to move forward. To facilitate this type of behavior in WS-BPEL, we introduce
the notion of atomicity that (a) guarantees all-or-nothing semantics (b) induces rollback-and-retry
on transient errors and (c) induces rollback-and-fault on persistent errors.
> We define atomicity in terms of the "atomic" extension attribute (marked "yes"), which
may be applied on the following WS-BPEL elements:
> a) The <process> element, which denotes the top-most unit-of-work, and has an implicit
scope of its own. If the process starts with an inbound message activity, then in case of
a rollback, the process will block until a new message is received.
> b) The <scope> element, which denotes a fine-grained unit-of-work and provides
the context for its enclosed activity. If the scope starts with an inbound message activity,
then in case of a rollback, the scope will block until a new message is received.
> c) The <onEvent> element, which denotes a concurrent unit-of-work and is triggered
by an inbound message. Note that its atomicity is independent of that of its enclosing scope.
Also, while the child within an event handler is always a <scope> activity, making that
atomic will not cause the process to block until a new event arrives.
> Note that in order to achieve the all-or-nothing behavior, we must begin, commit or rollback
a JTA global transaction when the execution of an atomic element starts, succeeds or fails,
respectively. In addition, we implicitly commit the process when it hits a blocking activity,
such as a receive. Consequently, we disallow the use of a <receive> activity anywhere
inside an atomic activity, except as its first basic activity. A healthy side-effect of this
constraint is that it frees us from deadlocks that might otherwise arise due to circular service
> The retry logic of atomic activities may be configured using the following two configuration
> a) scopes.atomic.retry.count: This number indicates the number of times the atomic activity
will be "retried" before it gives up, which defaults to 3. Specifically, it may be executed
at most one more time than this count. Strictly speaking, the first attempt at executing the
atomic activity is not considered to be a "retry".
> b) scopes.atomic.retry.delay: This number indicates the number of seconds the process
will wait before "retrying" a previously failed atomic activity, which defaults to one minute.
> If the atomic activity successfully completes during its first try or one of its subsequent
retries, the process will proceed to the following activity, as it normally would have. If
the atomic activity repeatedly fails and the allowed number of retries is exceeded (i.e.,
the error is no longer transient, but rather persistent), it will in turn throw a ode:scopeRollback
fault, which may be caught and handled by one of its enclosing scopes (or not).
> Let us now discuss the rollback aspect of an atomic activity. In the event of a failure,
before we retry it, we will revert the state of the process back to the point when it was
just about to commence execution. As a result, we discard any change to the process state
caused by copy operation assignments, message activity variable and correlation initialization,
link status evaluations, and so on. Furthermore, one-way messages meant to be sent on success
are discarded and two-way messages already sent have the consumed service rolled back. Speaking
of two-way messages, we limit the scope of our initial implementation to message exchanges
with processes and services that co-exist in the same server (node). Supporting atomicity
across external services would require the use of a web service transaction protocol such
as WS-AtomicTransaction, but that standard is neither specified nor implemented fully.
> For more details, please refer to http://ode.apache.org/atomic-scopes-extension-for-bpel.html.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message