[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Serializable Scopes Issues?
I actually cannot recall why we have banned all nested scopes inside serializable scopes -- I will check. The reson for banning nesting of serializable scopes themselves is to avoid requiring any nested locking scheme for implementing BPEL. Loosening the leaf restriction doesn't seem to help though since the fault would presumably occur upon exiting the serializable scope and therefore would be handled in one of its fault handlers, which we already allow. What were you thinking of proposing there? By custom code I meant fault handlers that would somehow (no idea how) cope using business process logic. ________________________________ From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM] Sent: Wed 10/22/2003 7:16 AM To: Satish Thatte Cc: wsbpel@lists.oasis-open.org Subject: Re: [wsbpel] Serializable Scopes Issues? Ron Ten-Hove wrote: > Satish Thatte wrote: > >> What did you have in mind for the handling of concurrency faults? >> Retry? Failure? Some custom code? >> > This is really a specific case of the more general problem of fault > handling / recovery in BPEL. The language should have decent support > for this. In this case, I might follow a typical pattern: compensate > for the activities completed in the failed scope, then retry it. > Nothing fancy like custom code, as much as I admire Edwin's <exec> > tags :-). Hum. Upon reflection, I think the error handling might be more difficult than I originally thought. The fact that a serializable scope must be a leaf scope makes structuring error handling within the scope in question more difficult. This brings up the question: what would be the cost of allowing nested scopes within a serializable one? Effectively it would function as one collective serializable scope, but would make structuring fault and compensation handling within the serializable scope more flexible. Also, upon further relection, what did you mean by "custom code"? Did you mean a user-defined fault handler for concurrency faults? -Ron
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]