OTS 1.0 NO IDEA Avatar
  1. OMG Issue

OTS — OTSPolicy & OTS internal operations

  • Key: OTS-36
  • Legacy Issue Number: 4030
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    All "OTS enabled" object references have a componet with an OTSPolicy
    that contains one of three policy values: REQUIRES, FORBIDS and ADAPTS.

    Any object reference without this OTSPolicy is assumed to be a non OTS
    1.2 policy.

    The behaviour of the caller is then driven by the value of the
    NonTxTargetPolicy. Assuming the caller is in a transaction:

    If this value is PERMIT the method invocation proceeds without
    propagating the transaction information and any exceptions that result
    are ignored (since the object cannot participate in the transaction). If
    this value is PREVENT the client is notified via an exception.

    Note that the value of the NonTxTargetPolicy is strictly under client
    control.

    Problem:

    Under the covers calls to the OTS server to implement the implicit
    transaction propagation are presumambly normal CORBA invocations – and
    hence go through normal channels (and through the portable interceptor
    calls, etc). What OTSPolicy value (if any) does the OTS server export
    for its object references?

    If there is no OTSPolicy value and the NonTxTargetPolicy is PREVENT
    calls with be refused. If there is an OTSPolicy value (presumambly
    ADAPTS) and the call to the OTS results in (an expected exception)
    then the transaction will be aborted (because exceptions cause the
    transaction to be marked rollback-only).

    The real problem is that the OTS implicit client side support must be
    able to recognize the invocation to the OTS server as somehow
    different from regular method invocations.

    Solution(s):

    We've identified two possible strategies to handle this problem:

    1/ Add a new policy value to the OTSPolicy - INTERNAL. On the client
    side references with INTERNAL don't have a PropagationContext sent
    and the objects do not participate in the transaction. In addition
    INTERNAL objects ignore the NonTxTargetPolicy.

    2/ Internally in the OTS runtime mark references that are "internal"
    with a specific proprietary policy. In the client side interceptor
    references with this policy are treated as "internal" as above.

    #1 is the easiest to implement since no special action is needed in
    the OTS runtime (besides the obvious action when INTERNAL is seen).
    However, it requires a change to the spec and change by all vendors.

    #2 is the least intrusive from the specification POV. However, it's a
    pain to implement. Vendors must ensure that all internal references
    have the correct policy overrides installed on all internal
    references. This in practice is not as easy as it sounds

    I've implemented both approaches and as far as I can tell they both
    work.

  • Reported: OTS 1.0b1 — Tue, 24 Oct 2000 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    see above

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