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] 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_workgroup.php.




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