You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2009/02/15 17:25:02 UTC
Re: [Proposal] Supporting Concurrent Exception Handling at Tuscany
SCA
Hi Douglas
Interesting post. Look forward to seeing what you come up with. Re.
"Maybe the travel agency sample, given above, is too simple to justify the
use of such complex (and maybe expensive) mechanisms"
Maybe it's not simple enough in the very first instance? In the travel agent
sample you have 2 concurrent business processes executing where each process
takes the form:
Book
Pay
What would be lost to your scenario if you considered Book and Pay an atomic
operation which leaves you with four combinations;
success
hotels fails (either flight has or hasn't run)
flight fails (either hotel has or hasn't run)
concurrent exception
Just a thought.
Regards
Simon
Re: [Proposal] Supporting Concurrent Exception Handling at Tuscany
SCA
Posted by Douglas Leite <do...@gmail.com>.
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 <lu...@gmail.com>wrote:
> On Mon, Mar 9, 2009 at 8:21 PM, Douglas Leite <do...@gmail.com>
> 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
Re: [Proposal] Supporting Concurrent Exception Handling at Tuscany
SCA
Posted by Luciano Resende <lu...@gmail.com>.
On Mon, Mar 9, 2009 at 8:21 PM, Douglas Leite <do...@gmail.com> 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/
Re: [Proposal] Supporting Concurrent Exception Handling at Tuscany
SCA
Posted by Douglas Leite <do...@gmail.com>.
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 <lu...@gmail.com>wrote:
> On Sat, Feb 21, 2009 at 11:07 AM, Douglas Leite <do...@gmail.com>
> 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
Re: [Proposal] Supporting Concurrent Exception Handling at Tuscany
SCA
Posted by Luciano Resende <lu...@gmail.com>.
On Sat, Feb 21, 2009 at 11:07 AM, Douglas Leite <do...@gmail.com> 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://lresende.blogspot.com/
Re: [Proposal] Supporting Concurrent Exception Handling at Tuscany
SCA
Posted by Douglas Leite <do...@gmail.com>.
Hi Luciano,
In fact, the models that I have presented before can be seen as "patterns"
to handle concurrent exceptions in distributed systems. My proposal is to
adapt them to work with the SCA and its bindings.
The idea is to create a framework that allows specifying the distributed
concurrent exception handling, based on the models. Maybe this could be
described in the SCDL file, or maybe in another XML file. Specifics
annotations could be created too. Another approach could be the use of an
AOP language. All of them are just speculations, and more discussions and
studies need to be done. However, I do not know how big is the impact of the
usage of these approaches on the SCA Runtime.
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?
On Wed, Feb 18, 2009 at 3:47 AM, Luciano Resende <lu...@gmail.com>wrote:
> Douglas
>
> If I understood your proposal, it looks like you are investigating
> a "pattern" or "best practice" to handle exceptions in SCA components.
> Do you envision any requirements on the SCA Runtime to support this ?
>
> On Sun, Feb 15, 2009 at 8:25 AM, Simon Laws <si...@googlemail.com>
> wrote:
> > Hi Douglas
> >
> > Interesting post. Look forward to seeing what you come up with. Re.
> >
> > "Maybe the travel agency sample, given above, is too simple to justify
> the
> > use of such complex (and maybe expensive) mechanisms"
> >
> > Maybe it's not simple enough in the very first instance? In the travel
> agent
> > sample you have 2 concurrent business processes executing where each
> process
> > takes the form:
> >
> > Book
> > Pay
> >
> > What would be lost to your scenario if you considered Book and Pay an
> atomic
> > operation which leaves you with four combinations;
> >
> > success
> > hotels fails (either flight has or hasn't run)
> > flight fails (either hotel has or hasn't run)
> > concurrent exception
> >
> > Just a thought.
> >
> > Regards
> >
> > Simon
> >
>
>
>
> --
> 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
Re: [Proposal] Supporting Concurrent Exception Handling at Tuscany
SCA
Posted by Luciano Resende <lu...@gmail.com>.
Douglas
If I understood your proposal, it looks like you are investigating
a "pattern" or "best practice" to handle exceptions in SCA components.
Do you envision any requirements on the SCA Runtime to support this ?
On Sun, Feb 15, 2009 at 8:25 AM, Simon Laws <si...@googlemail.com> wrote:
> Hi Douglas
>
> Interesting post. Look forward to seeing what you come up with. Re.
>
> "Maybe the travel agency sample, given above, is too simple to justify the
> use of such complex (and maybe expensive) mechanisms"
>
> Maybe it's not simple enough in the very first instance? In the travel agent
> sample you have 2 concurrent business processes executing where each process
> takes the form:
>
> Book
> Pay
>
> What would be lost to your scenario if you considered Book and Pay an atomic
> operation which leaves you with four combinations;
>
> success
> hotels fails (either flight has or hasn't run)
> flight fails (either hotel has or hasn't run)
> concurrent exception
>
> Just a thought.
>
> Regards
>
> Simon
>
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: [Proposal] Supporting Concurrent Exception Handling at Tuscany
SCA
Posted by Douglas Leite <do...@apache.org>.
Hi Simon,
In this example, due to the fact that the actions made when an exception is
raised are towards recovering the system to a consistent state (compensation
actions are executed), I think the use of book and pay operations as an
atomic operation would not affect the essence of the exceptional behavior of
the scenario.
As you observed, we would have less cases, since now book/pay can be seen as
an atomic operation. When some error is detected within the atomic
operation, it tries to put the system into a consistent state, then it
signals to the composed context an exception, just to information.
However, maybe for another scenario, we could not have actions towards
recovering the system to a consistent state, but actions which execute some
exception treatment logic and try to go on with the operation execution. In
the fault-tolerance area, we call this behavior as forward error recovery.
On Sun, Feb 15, 2009 at 1:25 PM, Simon Laws <si...@googlemail.com>wrote:
> Hi Douglas
>
> Interesting post. Look forward to seeing what you come up with. Re.
>
> "Maybe the travel agency sample, given above, is too simple to justify the
> use of such complex (and maybe expensive) mechanisms"
>
> Maybe it's not simple enough in the very first instance? In the travel
> agent sample you have 2 concurrent business processes executing where each
> process takes the form:
>
> Book
> Pay
>
> What would be lost to your scenario if you considered Book and Pay an
> atomic operation which leaves you with four combinations;
>
> success
> hotels fails (either flight has or hasn't run)
> flight fails (either hotel has or hasn't run)
> concurrent exception
>
> Just a thought.
>
> Regards
>
> Simon
>
--
Douglas Siqueira Leite
Graduate student at University of Campinas (Unicamp), Brazil