CORBA 3.0 MAILINGLIST Avatar
  1. OMG Issue

CORBA3 — Detecting Recursion in Other Interceptors

  • Key: CORBA3-36
  • Legacy Issue Number: 4554
  • Status: closed  
  • Source: International Business Machines ( Tim Baldwin)
  • Summary:

    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?

  • Reported: CORBA 2.5 — Tue, 4 Sep 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT