Re: [wsbpel] Issue 3 -- proposal for discussion

[Assaf Arkin <arkin@intalio.com>]

I also prefer option #2.

It was not clear if this is the intent, but I would want to see the 
compensation handler able to read and write variables defined in its 
scope. By that definition the scope variables become immutable only if 
the scope completes without installing compensation handler, the 
compensation handler does not get invoked, or after the compensation 
handler was invoked.

arkin

Satish Thatte wrote:

>Jim,
>
>You are absolutely right.  Snapshot is probably an outdated word for
>option#2.  It is exactly the state of the scope being preserved after
>completion because there is a possible continuation through
>compensation.
>
>Satish
>
>-----Original Message-----
>From: Jim Clune [mailto:jim@parasoft.com] 
>Sent: Friday, October 10, 2003 1:17 PM
>To: Satish Thatte; wsbpel@lists.oasis-open.org
>Subject: Re: [wsbpel] Issue 3 -- proposal for discussion
>
>Thanks, Satish. That does help clarify. I also like proposal #2 better
>than
>#1 partly because I find the notion of having multiple writable copies
>of
>variables that may or may not have the same values (present in proposal
>#1)
>to be confusing and error prone. I think I would find this less
>troublesome
>if the copied variables were read-only, but I think proposal #2
>simplifies
>the situation and avoids the issue altogether.
>
>Perhaps I'm just getting hung up on the term "snapshot" here, but as I
>think
>about a BPEL engine implementation it still seems to me that proposal #2
>does not require a snapshot in the sense of making a copy of the
>variables
>and link states. It makes sense to me that the original state must be
>maintained beyond what would normally be considered the lifetime of the
>scope, but it seems to me that no copy of the scope's state is required,
>since a given scope's execution can be compensated for at most once. If
>the
>compensation handler modifies any state in a completed scope, it can go
>ahead and modify the original values because any subsequent compensation
>handler that attempts to compensate the same scope instance will result
>in a
>repeatedCompensation fault. Again, this may be just terminology, as I am
>(perhaps incorrectly) coupling the idea of a snapshot with the idea of
>making a copy of the state.
>
>Jim Clune
>Parasoft Corporation          email: jim.clune@parasoft.com
>101 E. Huntington Ave.      voice: (626) 256-3680
>Monrovia, CA.  91016           fax  : (626) 305-9048
>----- Original Message ----- 
>From: "Satish Thatte" <satisht@microsoft.com>
>To: "Jim Clune" <jim@parasoft.com>; <wsbpel@lists.oasis-open.org>
>Sent: Thursday, October 09, 2003 7:10 AM
>Subject: RE: [wsbpel] Issue 3 -- proposal for discussion
>
>
>Proposal#2 does keep the notion of snapshots but snapshots always
>reflect the state of a scope as it was when it completed successfully.
>If a compensation handler refers to variables in the local scope it gets
>snapshot variables.  If it refers to variables in its enclosing scope
>what it gets depends on how it is called.  If it is called from the
>compensation handler of the enclosing scope it gets the snapshot
>variable that the caller is also seeing.  If it is called from a fault
>handler it sees the live state of the enclosing scope.  And the same
>thing continues to further enclosing scopes recursively.
>
>In proposal#1 a compensation handler lives entirely in its own private
>snapshot and has no way to see or affect any state any other part of the
>process can see *except* for the incoming and outgoing parameters.
>However, within its snapshot of the universe (i.e., all enclosing scopes
>upto process scope) it can merrily assign values to anything including
>partnerLinks.  This only affects its snapshot.  Except for the
>parameters part, this is the current semantics.
>
>Hope that helps.
>
>Satish
>-----Original Message-----
>From: Jim Clune [mailto:jim@parasoft.com]
>Sent: Wednesday, October 08, 2003 9:43 AM
>To: wsbpel@lists.oasis-open.org
>Subject: Re: [wsbpel] Issue 3 -- proposal for discussion
>
>I could use some clarification for these proposals. Is proposal #2 any
>different from just throwing out the notion of snapshots and having all
>activities use the same state?
>
>Could someone clarify for proposal #1 how write operations are impacted?
>When executing a compensation handler in a snapshot world, what happens
>when
>the compensation handler attempts to assign a new value to a variable
>that
>is visible to activities that are still executing in the live state?
>(For
>example, a process level variable.) I am referring to an assignment that
>attempts to assign to the variables directly, not through the proposed
>inbound/outbound parameters. Does this:
>1. Assign the new value to the snapshot version of the variable without
>impacting the "real" variable? (Might this be described as cloned
>variables
>as opposed to a frozen snapshot?)
>2. Throw a fault? (Which fault?)
>3. Get detected and prevented by static checking? (Is this always
>possible?)
>
>Jim Clune
>Parasoft Corporation          email: jim.clune@parasoft.com
>101 E. Huntington Ave.      voice: (626) 256-3680
>Monrovia, CA.  91016           fax  : (626) 305-9048
>
>
>To unsubscribe from this mailing list (and be removed from the roster of
>the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
>oup.php.
>
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of
>the
>OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
>oup.php.
>
>
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
>  
>