[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 3 -- proposal for discussion
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]