axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glyn Normington" <glyn_norming...@uk.ibm.com>
Subject Re: [Architecture Improvement] Handler lifecycle events and undo()
Date Tue, 18 Dec 2001 11:11:25 GMT
Doug wrote:

>>>     6 - when a error happens
>>>         - allow a handler that was previously invoked() to
>>>           perfom some action when another handler, later on,
>>>           faults.  Whether this is as complex as rollback()
>>>           or simply a logError() type of thing is up to it.
>>I don't understand the scope here. What if a client node A calls an
>intermediary node B which forwards the request to a server node C and
>then the response flows back to B and then back to A and then a fault
>occurs. Which handlers would get notified? All those in A, B, and C
>which had already run or just those in A which had already run?
>
>All we care about is what happens within a single SOAP engine
>and we don't mandate what happens within each handler.

I think we do care how a distributed collection of SOAP engines
behave, especially in particular configurations with particular
handlers present. That's the end-to-end view that the customers
will have. We can restrict our attention to a single SOAP engine
from the point of view of the code providing the overall effect
is desirable.

>You
>need to distinguish between a fault on "this" node and a fault
>on the "next" node.  A fault on the next node would not cause any
>fault chains on this node to be invoked (it is an option I guess
>but we never talked about it), rather a response handler is responsible
>for processing the response message - which would include examining
>it to see if it is a fault or not and do something if it wants.
>A fault on "this" node is different - from an Axis' point of view
>the entire chain (or set of chains) makes up "this" node and when
>something causes a fault in "this" node, "this node (ie. the handlers)"
>needs to be notified.

If we acknowledge such a discontinuity between "this" node and the "next"
node, then don't we have to treat the pre-pivot and post-pivot handlers in
this node separately with respect to fault processing? You see, it seems to
me that once we have passed the pivot point on a particular node, the
pre-pivot handlers have done their job and shouldn't be keeping state
particular to that request. If they are not interested in failures on the
"next" node, why would they be any more interested in failures in the
post-pivot handlers?

Glyn



Mime
View raw message