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://lresende.blogspot.com/
