TRANS 1.3 NO IDEA Avatar
  1. OMG Issue

TRANS13 — IORs without policies?

  • Key: TRANS13-33
  • Legacy Issue Number: 3425
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    ptc/99-10-07 is silent about what an OTS should do if the client invokes
    an object that does not have transaction policies in its IOR.

    For an IOR without a transaction policy, there are two cases:

    • The object inherits from TransactionalObject (is a legacy OTS object)

    In this case, the logical thing to do would seem to send the
    transaction context.

    • The object does not inherit from TransactionalObject

    It's a little less clear to me what to do in this case.
    During the discussion we had in Denver, the feeling was that

    1) the context should be sent anyway

    2) the receiving ORB should be obliged to use the the
    transaction context it received and send that same
    transaction context with any nested calls it makes
    to other objects

    Currently, the spec does not contain any words that would force
    point (2).

    Overall, it seems to me that sending the transaction context unconditionally
    is probably the best thing to do. Quite often, the client ORB will be forced
    to send an is_a message over the wire to determine whether or not an
    object inherits from TransactionalObject. That's an extra round-trip,
    which isn't cheap. Assuming that, if a client uses transactions, most
    of the objects it talks to will indeed be transactional, the cost of
    unconditionally propagating the transaction context would be minimal.
    And, given that for almost all calls, the cost is dominated by the
    dispatch delay, it seems that the extra bytes for the context wouldn't
    noticably hurt performance.

    At any rate, we need to specify the behavior for context propagation for:

    • the client side, for both TransactionalObject interfaces and
      ones that don't inherit from TransactionalObject
    • the server side, stating how the server must behave for nested
      calls
  • Reported: TRANS 1.1 — Wed, 15 Mar 2000 05:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    resolved, see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT