[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Resolution to issue 10 - Implicit compensation Handler
The problem I was referring to was: even if you KNEW the completion order by some magic of shared data, there is no way to write custom handlers to do anything except depth-first traversal (either sequential or parallel) of the tree of compensation handlers, because no control dependencies across non-nested compensation handlers are allowed in explicit models. Whereas the proposal I made for default compensation order enables a certain amount of breadth-first traversal with implied control dependencies across non-nested compensation handlers. Satish -----Original Message----- From: Yaron Goland [mailto:ygoland@bea.com] Sent: Friday, December 12, 2003 9:46 AM To: Satish Thatte; 'Sid Askary'; wsbpel@lists.oasis-open.org Subject: RE: [wsbpel] Resolution to issue 10 - Implicit compensation Handler Hum.... I'm not sure what you mean. I put some thoughts below as to what I think you might mean but I'm guessing I missed the particular scenario you are discussing. Could you please expand on your point about custom handlers not being able to do what default handlers can do? Thanks, Yaron P.S. The default compensation handler has two magical abilities - it can compensate all sub-scopes even if they aren't named and it can do so in the reverse order in which they were created (with some sort of tie breaking algorithm). For a custom compensation handler to replicate the "call compensation on all sub-scopes' behavior it must be able to find all its sub-scopes which only requires that they all be named. That is kind of a pain but doesn't seem too onerous. The spec even provides for the special sub-case where you have a sub-scope contained in a loop. Section 13.3 says "If a scope being compensated by name was nested in a loop, the instances of the compensation handlers in the successive iterations are invoked in reverse order." So I would say that the custom compensation handlers can safely pass the bar of 'call compensate on all sub-scopes', you just need to make sure they are all named. The second bar, the ability to call compensation handlers in the reverse order in which they were completed, is impossible to pass for custom compensation handlers in cases where a flow without links is involved since it is impossible to know at design time when the flows will finish at run time. One possible, deeply nasty, solution to this problem is to stick links into the last activities in the flows so as to force a certain completion order but I suspect that rather misses the point. I can imagine how we could solve this problem but it seems like more trouble than it is worth. What's the use case? > -----Original Message----- > From: Satish Thatte [mailto:satisht@microsoft.com] > Sent: Thursday, December 11, 2003 5:26 PM > To: ygoland@bea.com; Sid Askary; wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Resolution to issue 10 - Implicit compensation > Handler > > > Sid and Yaron, > > My main concern with my own proposal is the fact that the default > behavior cannot be achieved with custom handlers, which is a > fault in my > proposal. Someone (cannot recall who) brought that up during the face > to face and it gave me pause. Need to think about that some more. In > the mean while let us wait for Peter's comments. > > Satish > > -----Original Message----- > From: Yaron Goland [mailto:ygoland@bea.com] > Sent: Thursday, December 11, 2003 3:42 PM > To: 'Sid Askary'; wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Resolution to issue 10 - Implicit compensation > Handler > > +1 > > > -----Original Message----- > > From: Sid Askary [mailto:saskary@nuperus.com] > > Sent: Tuesday, December 09, 2003 1:46 PM > > To: wsbpel@lists.oasis-open.org > > Subject: [wsbpel] Resolution to issue 10 - Implicit > > compensation Handler > > > > > > Satish, > > As I said, I think your solution (the reverse temporal order) > > is a good one. I think I have a simple compromise: that we > > add a sentence to the effect that > > > > " Note: Sole reliance on implicit compensation handlers as a > > programming construct or as a means of defining default > > system behavior is not recommended." > > > > This may address both the "programmatic" (Yaron's) and > > default behavior (my own) assumptions. > > > > Not sure about Peter's concern. > > > > - Sid. > > > > > > > > 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/le > > ave_workgroup.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/le ave_workgr oup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]