TRANS13 — IORs without policies?

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

resolved, see below