Using the notion of the Guardian Model, we need to provide a way to annotate all the exceptions that will be managed by the guardian. In this way, when this kind of exception is signaled by an asynchronous process, it is sent to the guardian, instead to the caller process. Thereafter, using the recovery rules defined by the user, the guardian can verify which exception should be raised in each process. This scheme also works properly when concurrent exceptions are signaled.
The guardian works based on the notion of contexts. So, when the guardian signals an exception in a participant, it specifies in which context the exception should be treated (target context). Was that what you had in mind? On Wed, Mar 11, 2009 at 2:37 PM, Luciano Resende <[email protected]>wrote: > On Mon, Mar 9, 2009 at 8:21 PM, Douglas Leite <[email protected]> > wrote: > > Hi Luciano, > > > > This is right, and maybe one of the reasons that the specification > doesn't > > allow the use of @OneWay over methods that can throw an exception, is > > because the issues it can generate. > > > > A simple example: If we have two methods (let's call a and b) annotated > with > > @OneWay, and at certain point in a, the method b is invoked, so it > doesn't > > matter if a or b finishes firstly, since there is no message dependency > > among them (following the specification the methods must be void return > > type, and must not throw exceptions). > > > > Allowing @OneWay over methods that can throw an exception is a > complicating > > factor in this scenario. Let's consider that b throws an exception, and > is > > annotated with @OneWay (hypothetically, since it is not allowed by the > SCA > > spec). So we would have the following cases: > > > > 1) b throw an exception and a is still executing. > > 2) b throw an exception and a has finished its execution. > > > > In a normal exception flow, an exception thrown by b should be raised and > > treated in a. In this manner, both cases have problems. In the first > case, > > although the method a is running when the b throws an exception, nothing > is > > said about the context that a is executing, in other words, the method a > > need to be in a proper exceptional treatment context when the exception > is > > thrown by b. In Java language, it is like to declare all the code of > method > > a (starting at the point that method b is invoked) within a try block. > > > > The second case would introduce an error at the system, since the > exception > > thrown by b cannot be propagated to a. A way to solve this, is to let a > > waiting for b finishes its execution, before go on its activity. But, if > we > > do that, the @OneWay specification is not respected, and we broke the > > execution independence among the methods. So, in fact, we cannot do it. > > > > The mentioned solution is too simple, and doesn't solve the problem at > all. > > We need a powerful mechanism to control the flow of distributed > exceptions, > > like CA actions or the Guardian Model (more details at my first post in > this > > thread). In such kind of mechanisms, the exception flow is not too > simple. > > In the CA action for example, the exceptions are raised to each > participant > > of the composed service, and they come in and exit synchronously in the > > action. The synchronous exit avoid the problem of one participant > finishes > > its execution before another one. Note that the entry and exit points are > > synchronous, but the executions of the action’s participants are > > asynchronous. On the other hand, the guardian model is based on the > notion > > of a global entity (the guardian) that coordinates the exception > handling. > > > > Let me know if you need more clarifications. > > > > > A possible way to address this issue is to inject a global exception > handler component (e.g @GlobalExceptionHandler) to a given component > that will be invoked as @OneWay, and let that component handle the > failure and execute any compensation actions required (like calling a > callBack in the callerComponent responsible for executing the > compensation actions), instead of returning control to the caller, > that I think would broke the @OneWay paradigm. > > How does that sound like ? Is that the notion of "the guradian" that > you mentioned ? > > > -- > Luciano Resende > Apache Tuscany, Apache PhotArk > http://people.apache.org/~lresende <http://people.apache.org/%7Elresende> > http://lresende.blogspot.com/ > -- Douglas Siqueira Leite Graduate student at University of Campinas (Unicamp), Brazil
