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. Regards On Thu, Mar 5, 2009 at 1:35 AM, Luciano Resende <[email protected]>wrote: > On Sat, Feb 21, 2009 at 11:07 AM, Douglas Leite <[email protected]> > wrote: > > I think that a starter point could be allow the use of @OneWay annotation > in > > methods that can throw exceptions. In this way, we would allow the usage > of > > exceptional concurrent methods. > > > > Thoughts? > > This might not be a good idea, see a small snipet from SCA spec : > > 255 Nonblocking calls represent the simplest form of asynchronous > programming, where the client of > 256 the service invokes the service and continues processing > immediately, without waiting for the > 257 service to execute. > 258 Any method with a void return type and which has no declared > exceptions can be marked with a > 259 @OneWay annotation. > > > -- > 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
