OTS11 — OTS interop issue: propagation of current trx status

The OTS spec currently does not mandate that if a client thread in OTS domain A
invokes a server thread in OTS domain B, the current transaction status is
propagated back to the OTS in domain B such that the OTS in domain A is capable
of updating the status of the current transaction and providing accurate
information to the application e.g. when queried using Current::get_status.
(With current transaction I am referring to the transaction whose id would be
passed in the 'current' field in case of a PropagationContext transferral.)

However, if the transaction status of the current transaction changes as a
result of a transactional object invocation in domain B, then updating the
current transaction status in domain A is useful for the applications that
query the current transaction status after an invocation. It is also useful for
the other applications that don't query the status because the OTS in domain A
then can prevent further pointless invocations if the transaction has been
marked for rollback.

This feature is that useful that the OTS should guarantee that the transaction
status is propagated back.

Possbile resolutions:
---------------------
(a) As has been shown in previous discussion this can be solved by mandating
how interoperable OTSs have to do it based on the current specs.

(b) A more efficient solution would be, that the current transaction status is
propagated back in an interoperable way as part of the reply, e.g. by

• introducing a new ServiceId TransactionService_2_0 in chapter 13 of CORBA
• defining a new propagation context
  struct PropagationContext_2_0
  { unsigned long timeout; TransIdentity current; sequence<TransIdentity> parents; Status current_status; any implementation_specific_data; }

  ;

• prior to portable interceptors: extend the Sender and Receiver interfaces
  with new operations that support the new propagation context