CORBA3 — Detecting Recursion in Other Interceptors

We have identified a requirement where the interceptors for one service
need to be able to detect recursive invocations made by some other
interceptor during the processing of a request. As far as we have been
able to determine there is no way to achieve this using the
Request-scope/Thread-scope Current mechanism described in the spec.

It is probably easiest to explain this using a specific example. Start
with some form of "transaction" service that registers client-side
interceptors so it can detect all new request invocations and add service
contexts that perform some form of "begin transaction" processing at the
server. This transaction service must only perform this "begin
transaction" once per application-level request, so it allocates a
PICurrent slot and performs the processing described in section 21.4.4.2 to
ensure that any recursive calls it makes itself will form part of the same
transaction and not begin a new one.

However a problem now occurs if we introduce some other service, say a
"security" service that has its own interceptors registered. The order in
which these two service's interceptors run can affect what happens, but
since interceptor ordering is undefined assume that the security
interceptor runs first.

An application makes a request on its own thread A. The send_request
interceptors start to run on thread B and the security interceptor runs
first, at this point both the RSC and TSC slots for the transaction service
are empty. The security interceptor makes a recursive request so the
send_request interceptors run again on a new thread C. The security
interceptor runs again and this time doesn't recurse so the transaction
interceptor now runs on thread C. At this point it finds its RSC slot
empty so does a "begin transaction" and sets its TSC for thread C. We've
now finished interceptors on thread C and return to thread B and invoke
send_request for the transaction service. Once again it finds its RSC slot
empty and will try to "begin transaction" again. Now we have a problem as
we have issued two "begin transactions" for the same application request.

In fact it as actually the second of those two "begin transactions" that we
really want to do, as that represents the true start of the application's
transaction. The first one (caused by the recursive call in the other
interceptor) is at best redundant and wasteful and at worst wrong and
problematic.

Does anyone have any comments on this problem?

close no change