When a child Activity completes, its parent's ActivityCoordinator must
drive the childComplete/childLifetime SignalSet to produce the
childComplete signal for distribution to any Actions with an interest in
this signal. This Signal contains an ActivityInformation structure that
indicates the GlobalId and final CompletionStatus of the completing
Activity. (A separate issues proposes that the final Outcome of the child
Activity also be included in the ActivityInformation). The specification
leaves it to an Activity service implementation to determine how a parent
Activity is notified of its child's completion and how the
ActivityInformation is obtained by the parent's childComplete/childLifetime
SignalSet. A practical approach is for the child ActivityCoordinator to
call its parent ActivityCoordinator's
process_signal_set("org.omg.childComplete") method. If the child Activity
is active on the thread when childCompletion processing occurs, then the
SignalSet in the parent can determine the child's GlobalId and
CompletionStatus via the Current interface. (Note: the completionStatus of
the child may be modified by the completion SignalSet during completion
processing; it is the final completionStatus that should be reported
during childComplete processing).

An interoperation issue arises if a child Activity is rooted on a node that
is downstream from the parent's root. In this case, childComplete signals
need to originate from the parent's root ActivityCoordinator/SignalSet.
Mechanically, the completing child should inform its (local) parent
ActivityCoordinator by whichever implementation-specific means it uses and
then the local (subordinate) parent ActivityCoordinator has to push this
back up to its ultimate superior for distribution throughout the tree. The
means by which this happens need to be defined to ensure interoperation
across different vendors' implementations. One approach would be for the
subordinate ActivityCoordinator to drive its superior's
process_signal_set() method, ensuring that the ActivityContext is
propagated on this flow (in order that the superior can obtain the child's
GlobalId). A similar consideration holds for childBegin. There are issues
with this approach; one is that any child Activity, begun at any node
downstream to its parent, will always have its context imported (as a
subordinate) to all upstream nodes on which its parent is active.
A different solution to the problem might be to introduce a new method on
the ActivityCoordinator interface that can be used during child-completion
to pass the ActivityInformation object. This would mean that no service
context would need to flowed and all the information required to deliver
the childComplete signal would be available to the parent. This could be
something like:
void ActivityCoordinator::set_child_completed(in ActivityInformation ai)
It would still be implementation-specific how that ActivityInformation got
added to the signal, but that is not an interoperation issue.

see above

This is a re-summarising of the interworking problem that came out in the
discussion of 3916. It is definitely NOT intended to destabilise the 3425
result, but to clarify a corner condition. I've tried to be precise rather
than brief, though I've undoubtedly misused some terms somewhere.

—
To identify some text that needs changing: the first sentence of the
following paragraph (middle of page 10-72 of 00-09-04) is not consistent
with the rest of the text:

OTS 1.1 clients may not interoperate with OTS 1.2 servers unless they
unconditionally
propagate the transaction context. (TF) The OTS 1.2 server determines the
proper
OTSPolicy from the TAG_OTS_POLICY component in the IOR.

—

And the situation in general, for 1.1 client, 1.2 server, for a target
object that is transaction-naive, with client in an active transaction

First, if both sides were 1.1, target would not inherit from TO
On most 1.1 implementations, client invocation-path would
drop/suspend the context.
Some implementations ("promiscuous") would send context.

1.1 server - some implementations would drop/not apply/suspend a
received context; some would just apply the received context (or an
interposed context derived from it) to the thread - this was assumed not to
matter for 1.1 [the 3425 discussion said this was a bug or close to a bug];
some would fault a received context with an exception. (configuration
options could switch between these in some implmentations (ours, at least))

With 1.2 server as we are now (00-09-04)
target's POA will have OTSPolicy of FORBIDS (often by default)

1.1 non-promiscuous will not send context as before - no problem
1.1 promiscuous will send context

1.2 server is required to fault the receipt of a propagation context
on the FORBIDS POA - it MUST throw an exception (INVALID_TRANSACTION).

This would mean a client ap within an active transaction on a promiscuous
1.1-ots platform cannot invoke a non-transactional object on a 1.2-ots.

There is no problem with transaction-using objects, provided the IDL
continues to inherit from TO, even on the 1.2 server. Promiscuous 1.1
clients will send anyway; non-promiscuous will narrow to TO and send the
context.

So - the TransactionalObject inheritance mechanism works for non-promiscous
1.1 clients, but not for promiscuous.

One possible solution would be to allow a setting on the server side
equivalent in effect to the NonTxTargetPolicy PREVENT/PERMIT - if set to
"lenient", it would silently remove the received context. Under no
circumstances would the context remain associated with the thread. (Note
this would be a quite different policy from the existing NonTxTargetPolicy
which affects only client-side behaviour and is for the benefit of client
application writers - this would be server-side only, mostly for the benefit
of interworking). This server-side setting could be a private configuration
switch, but that would be effectively have values "conformant" and
"useful" - which I think it is agreed is really, really bad. Making it yet
another policy would seem better.

Another "solution" would be to confirm that promiscuous 1.1 won't interwork
with 1.2.

—
In any case, the paragraph in 10-72 needs changing.

If we choose to reject the interworking, just change "unless" in the first
sentence of the paragraph to "if" (i.e. reverse the sense)

If we add a server-side policy, the 10-72 the paragraph might become
something like:

OTS 1.1 clients can interoperate with OTS 1.2 servers in the following
circumstances:

a) if the client propagates the context only if the target derives
from TO, then interoperation for both t and non-t target objects will be
possible, provided the target object's idl inherit from TO;

b) if the client always propagates the context (if in a T),
interoperation will be possible for t objects regardless of inheritance;

c) if the client always propagates the context, interoperation for
non-t objects will only be possible if the the server setting
UnwantedCtxPolicy is MAKERIGHT. Interworking in this case is not possible if
the UnwantedCtxPolicy is REJECT.

(deliberately choosing a slightly derogatory name for the moment !)

Of course, if UnwantedCtxPolicy is set to MAKERIGHT, it becomes possible
(i.e. it would work) to have the OTSPolicy checking at the client be
optional. But that would mean that contexts were also being sent to
OTS-unaware ORBs, which has been held to be undesirable, though for reasons
that are obscure.

see above

the lenient/fascist issue is about
whether, by default, a client that is currently in a transaction should
be allowed to invoke on a non-transactional object. The fascist option
means that, by default, the client gets an exception when it invokes
on a non-transactional object; the lenient option means that, by
default,
such an invocation is allowed.

Resolved by reference/clarification to 4808

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.

see above

The specification for register_resource does not define what should happen if a
resource is registered twice in the same transaction (page 1-22 of the
Transaction Services chapter).

On page 1-44 (In "Example of a Recoverable Server"), we finally get the words
"before registering the Resource, the object must check whether it has already
been registered for the same transaction." What this has to do with the example
is a complete mystery, as the example code immediately following this doesn't do
anything remotely like this.

The text I was quoting before goes on to opine that "This is done using the
hash_transaction and is_same_transaction operations on the current Coordinator
to compare a list of saved coordinators representing currently active
transactions". An interesting idea, but not good enough. What if another object
registers this resource?

The string of words that I have quoted above also fails to mention exactly what
will happen if a resource is registered twice in the same transaction.

I propose that the specification of register resource should actually specify
what the behaviour of the operation is, without requiring examples 22 pages
later to vaguely describe the error handling as an afterthought.

Finally, I would suggest that the only object that has the global knowledge
necessary to make this determination is the transaction itself. Therefore the
test for repeated registration must be in register_resource itself. What is left
to determine is if this is an error or (better) if the registration is silently
ignored.

see above

Messaging spec changes to OTS 1.1 removes the TransactionalObject interface. A couple of related
issues :

1) Section 10.3.8 dealing with Synchronization interface needs to specify the correct
TransactionPolicyValue that needs to be associated with the POA which hosts the Synchronization
objects. Possible values are Allows_shared or Requires_shared, i beleive.

2) The active transaction modes refered to in Section 10.5.2 ptc 99-10-07,

; how does the transaction manager start a transaction in one of these transaction modes ? I am
not sure if there is a way to specify the transacton mode while starting a transaction or while
associating the a transaction context with a thread. Could someone please clarify ?

see below

OTS 1.1 + Messaging spec additions to OTS 1.1 seems to provide a clean way for specifying
transaction interoperability. Even though, it does not guarantee that all current vendor
implementations will interoperate, the vendors will be able to interoperate if they strictly adhere
to the OTS protocol.

But we see issues with OTS interoperability when X/Open XA protocol is used by vendor
implementations to talk to XA-compliant Resource Managers
as part of a global distributed transaction across multiple servers.
Typically, every server involved in a distributed transaction will generate a new transaction branch
for the work done by that server as part of the global transaction.

This issue hinges on the need for a mechanism to ensure uniqueness of transaction branch generation.
This is very important when servers involved in a distributed transaction talk to the same RM. In
such a case, if uniqueness of transaction branches is not ensured, then it may cause
problems during regular 2PC flow or recovery processing.

This branch id generation is a non-issue if the participant servers are homogenous, since the
implementation_specific_data could be used to transmit proprietary information as part of the
transaction propagation context.

To summarize, if two servers (from different vendors) involved in a distributed transaction happen
to talk to the same RM using the same XID, then it may lead to problems during regular 2PC flow or
during recovery processing. It will be desirable to have some way of ensuring uniquess of branch ids
across servers involved in a distributed transaction.

see above

Some OTS implementations use the X/Open DTP XA interface to coordinate
resource managers. For example, the Oracle Application Server (OAS) contains
such an OTS implementation.
The OAS OTS does not implement or use the OTS Resource interface. As XA
resource managers are enlisted in a transaction, descriptors for them are
added to the TransactionContext::implementation_specific_data. When the
transaction is ready to commit, the set of enlisted RMs is handed over to a
coordinator process to drive the 2pc.

This leads to (at least) 2 problems:

1. the descriptors in the implementation_specific_data are not standard and
thus 2 different OTS implementations, both of which handle XA RMs, cannot
interoperate

2. there isn't any API to register an XA RM with the Coordinator. There
should be a method, e.g.:

Coordinator::register_XA_RM_info(string xa_driver_id, string xa_open_args)

This method would be called instead of Coordinator::register_resource when
using XA based resource managers rather than OTS Resource based resource
managers.

The xa_driver_id is like the RMID, but has global scope (the RMID is scoped
relative to an xa_switch vector, I think). For example, given an
xa_driver_id = "XA:ORACLE:1.0" and xa_open_args =
"somedbkey:somecomputer.somecompany.com" , 2 different OTS implementations
can expect to communicate with the same resource manager.

No Data Available

he specification for register_resource does not define what should happen if a
resource is registered twice in the same transaction (page 1-22 of the
Transaction Services chapter).

On page 1-44 (In "Example of a Recoverable Server"), we finally get the words
"before registering the Resource, the object must check whether it has already
been registered for the same transaction." What this has to do with the example
is a complete mystery, as the example code immediately following this doesn't do
anything remotely like this.

The text I was quoting before goes on to opine that "This is done using the
hash_transaction and is_same_transaction operations on the current Coordinator
to compare a list of saved coordinators representing currently active
transactions". An interesting idea, but not good enough. What if another object
registers this resource?

The string of words that I have quoted above also fails to mention exactly what
will happen if a resource is registered twice in the same transaction.

I propose that the specification of register resource should actually specify
what the behaviour of the operation is, without requiring examples 22 pages
later to vaguely describe the error handling as an afterthought.

Finally, I would suggest that the only object that has the global knowledge
necessary to make this determination is the transaction itself. Therefore the
test for repeated registration must be in register_resource itself. What is left
to determine is if this is an error or (better) if the registration is silently
ignored.

Duplicate of #3600, close issue

When using interposition it's possible for (and I'd argue it probably
should) a subordinate coordinator to run the two-phase commit protocol on
its registered resources (almost) independently of the root coordinator (or
the coordinator it's registered with). Say the subordinate coordinator gets
a prepare message which it then sends to its locally registered resources,
if one of them returns VoteRollback then the subordinate knows that it will
eventually have to rollback all registered resources. Now it could simply do
nothing more and send VoteRollback up the tree, knowing that it will
eventually get a rollback call to then distributed on to its registered
resources. Alternatively, it could send rollback to all of its resource
before sending the VoteRollback up the tree (and then it could obviously
go).

Although we shouldn't mandate an implementation, it might be useful to
mention the above optimisation in the text. Perhaps during the Implementor's
View.

close issue, see above

1) The OTS specification indicates that the Resource::prepare operation
can
raise a heuristic exception. This can appears when the Resource acts as
a sub-coordinator and at least one of its resources takes a heuristic
decision.

However I didn't find a clear text explaining the behavior or
"protocol" of
a coordinator which receives such exception.
What should be the decision of this coordinator regarding to others
resource
having replied with VoteCommit?

Roll back the transaction (see 3600 above)

P23: "An Action may register interest in more than one SignalSet and an
Activity may use more than one SignalSet during its lifetime."
P50: "An Action is implicitly associated with a single Activity and should
only be with that Activity. An Action may receive many different Signals
from different SignalSets."

The interface to register an Action with an Activity is add_action, on
either the ActivityCoordinator or Current interfaces. It is defined:
void add_action(in Action act, in string signal_set_name, in long priority)
raises(SignalSetUnknown);

If an Action is to be registered with an interest in more than one
SignalSet, then it must be passed as a parameter on multiple add_action
calls. Given that the specification implies that calling
ActivityCoordinator.add_action(TheAction, "someSS", priority)
multiple times is OK, the behaviour needs to be defined for the case where
TheAction is added multiple times to the same SignalSet. In particular,
what if the priority is different on multiple add_action calls?
At the very least I believe a new exception - ActionAlreadyRegistered? -
needs to be thrown in the case where an Action is registered multiple times
with the same SignalSet.

I question the need to support registering an Action with multiple
SignalSets at all. I propose that this be illegal as I believe there is no
need for it. The new exception is still required.

see above

The problem is that, in domain 2 where there is no SignalSet, how are the
Outcomes from Action1 and Action2 supposed to be combined and sent back as
a single Outcome to the superior ActivityCoordinator?
Further, even if the appropriate SignalSet did exist in domain 2, how could
the subordinate ActivityCoordinator get it involved in the request from the
superior - the interposed ActivityCoordinator is merely acting as a global
Action registered with its superior.

I propose the following in order to support interposition:
1. Any signal received by a subordinate ActivityCoordinator be delegated to
a SignalSet (assumed to be local since we're using interposition). If the
SignalSet is not available, then return a standard Outcome (that also needs
to be specified) that indicates that the subordinate ActivityCoordinator is
not interested in any further signals from this particular broadcast.
2. Extend the CosActivity::SignalSet interface to provide a
set_signal(signal) method to enable a subordinate ActivityCoordinator to
indicate to the SignalSet that it will be used only to process the
specified Signal (and the Outcomes that are subsequently produced by
Actions that receive the Signal) and not to actually produce any Signals.
Only the root SignalSet should be producing Signals.

An alternative would be to split the SignalSet into 2 objects - the
function of 1 object being to produce Signals and the other to combine
Outcomes. The down-side of this is the additional complexity it introduces
in terms of additional flows between the 2 parts of the SignalSet in the
root.
Another alternative would be to specialize the SignalSet with a
SubordinateSignalSet.

Update the specification to incorporate a new entity, the SubordinateSignalSet

PropertyGroup propagation
strategy on intermediate servers with no PropertyGroupManger.

The following section is taken from the Activity srevice specification
orbos/2000-06-19.
P58 "A PropertyGroupManager must be registered with each client and server
that wishes to use the type of PropertyGroup it represents."

Consider a configuration where objectA on serverA creates an Activity and
sets PropertyGroup data for PropertyGroup1 and then calls objectB on
serverB which calls objectC on serverC. The Activity service is configured
on all 3 servers. ObjectB and objectC can both access the PropertyGroup
data so long as a PropertyGroupManager for PropertyGroup1 is registered
with the Activity services on serverB and serverC. This is necessary
because a PropertyGroupManager is required to unmarshal the PropertyGroup
context received with the request arriving at each server.
What the specification does not define is whether or not all received
PropertyGroup contexts at serverB are propagated on downstream to serverC
if, for example, the PropertyGroupManager for PropertyGroup1 is not
registered with the Activity service on serverB. If the PropertyGroup1
context is never to be used on serverB then it would simplify deployment if
it were not necessary to configure a PropertyGroup1 PropertyGroupManager on
that server just to ensure that the PropertyGroupIdentity part of the
received context PGContext is propagated on downstream. It would also
improve performance as the PropertyGroup context would not need to be
unmarshalled, so long as the Activity service copied the marshalled
PGContext from the inbound request to the outbound downstream request.
This issue proposes that, in the case where an intermediate server has the
Activity service configured but not a particular PropertyGroupManager, all
PropertyGroupIdentities received with an inbound ActivityContext are
propagated on downstream in any outbound ActivityContexts.

It was agreed that this should be allowed, and text modifications proposed

The need for a default
system SignalSet for failure scenarios.
Malik originally requested this function so I'm raising it as an issue on
his behalf.

The following section is taken from the Activity srevice specification
orbos/2000-06-19.
P47: "If a SignalSet fails to produce Signals (e.g., it is physically
remote from the ActivityCoordinator and fails to respond to invocations),
then the completion status of the Activity is set to
CompletionStatusFailOnly, and the ActivityCoordinator should act
accordingly."

What does it mean by "should act accordingly", and what should be sent to
registered Actions if the (remote) SignalSet cannot be reached to produce
Signals?
Malik proposes a default SignalSet such as org.omg.SignallingFailure with
the signal "Failure", which should be sent to any Actions involved with the
unavailable SignalSet. This would require all Actions that cared about such
failure scenarios to be able to react to such a Signal. All Actions would
at least need to tolerate receiving such a Signal. We could go further and
define system Outcomes that Actions could return to the SignallingFailure
SignalSet and which could be percolated back up to Current::complete or
just define a new exception that could be thrown back up to
Current::complete. The important behaviour to provide is the ability for
the Actions in the failing Activity to be given the chance to register or
drive compensations or whatever recovery is necessary.

see above

The current specification defines ActivityPolicyValues that were based on
the OTSPolicyValues at a time of flux for the OTS specification. These are
currently:
const ActivityPolicyValue IGNORES = 0; // This is the default
const ActivityPolicyValue SUPPORTS = 1;
const ActivityPolicyValue REQUIRES = 2;
const ActivityPolicyValue REQUIRES_NONE = 3;

Since OTS 1.2 is now finalised, I believe we should follow the pattern
established by that specification and replace these policies with the
following:
const ActivityPolicyValue REQUIRES = 1;
const ActivityPolicyValue FORBIDS = 2;
const ActivityPolicyValue ADAPTS = 3;
I'm not sure which policy should be used as a default in the absence of an
explicit ActivityPolicy; I propose ADAPTS since FORBIDS seems a little
harsh.
The definitions for these policies should follow the equivalent OTSPolicy
definitions.
I don't believe we need any equivalent of the NonTxTargetPolicyValue
(required only for interoperation with OTS 1.1).

We need to define the policy that the Activity service objects themselves
should use to determine whether or not context is expected to flow on
operations on these objects. I believe this should be ADAPTS for all
Activity service objects.

Update the specification in line with the OTS

Section 2.2.1 says:
> If a SignalSet fails to produce Signals (e.g., it is physically remote
from
> the
> ActivityCoordinator and fails to respond to invocations), then the
> completion status of the
> Activity is set to CompletionStatusFailOnly, and the ActivityCoordinator
> should act
> accordingly.

We never actually intended SignalSets to be used remotely. I'd like to
recommend (on behalf of ourselves and IBM) that we use the local idl keyword
to make this explicit.

This issue is addressed by issue 4256, close issue

The following section is taken from the Activity srevice specification
orbos/2000-06-19.

P51: "It is not strictly necessary for an implementation of the Activity
Service to create an ActivityCoordinator prior to distributing a context
between execution
environments in which it was begun. Each Activity may be managed by at most
one ActivityCoordinator."
The description of Current::get_coordinator() is as follows:
"Returns a reference to the current Activity?s ActivityCoordinator. This
may be nil if a coordinator has yet to be created."

I believe that the act of trying to obtain the ActivityCoordinator should
cause it to be created if it doesn't exist already.
For example, it should be reasonable (on a server at least) to code:

CosActivity::Current_ptr cur;
CosActivity::ActivityCooridinator_ptr coord1, coord2;
...
curt->begin();
coord1 = cur->get_coordinator();
cur->begin();
coord2 = cur->get_coordinator();
coord2->is_same_activity(coord1); // This better be false! It shouldn't
blow up, either.
cur->complete();
cur->complete();

Thus, I believe get_coordinator() should never return nil.

As a second part of this issue some execution environments, for example a
lightweight client, may wish to restrict access to the Activity service
through the Current interface only. Further, some environments may wish to
limit restrict access to the Activity service to a subset of the Current
function, providing little more than the ability to begin and end an
Activity context and explicitly preventing the ability to register Actions
from the environment. For example, a client environment may not have the
capability to service inbound signals for Actions and so may not want to
allow local Action implementations to be registered. Another example is a
where recoverability of the Activity is required but a particular client
environment cannot provide this quality of service. So, I suggest that at
least the Current::get_coordinator() and add_action()/add_actions() methods
should provide an exception that can be thrown by an implementation in an
environment where use of the ActivityCoordinator or Action interfaces is
not intended. In no case would it be desirable for these methods simply to
return nil.

see above

The following section is taken from the Activity srevice specification
orbos/2000-06-19.

P63: "string get_completion_signal_set(): Returns the SignalSet
currently associated with the target Activity that will be used when it
completes. This will be the last valid SignalSet given to
set_completion_signal_set, or nil if one has not been provided."

Returning nil for a string if there is no completion_signal_set is
inconsistent with other methods in both the Activity and transactions
services which typically return empty strings in similar situations. For
example Current::get_activity_name().

I propose the description for get_completion_signal_set() be changed to:
Returns the SignalSet currently associated with the target Activity that
will be used when it completes. This will be the last valid SignalSet given
to set_completion_signal_set, or an empty string if one has not been
provided.

Change the text to disallow nil from being returned from get_completion_signal_set

If there are no Actions registered with a SignalSet when
ActivityCoordinator::process_signal_set() is called, then the
ActivityCoordinator will not ask the SignalSet for any Signals. However,
the SignalSet still needs to produce an Outcome. The description of the
get_outcome method suggests that the SignalSetActive exception could be
thrown if get_outcome is called before any Signals have been requested. The
description of this method should state that a SignalSet should return a
valid Outcome or nil if called before any Signals are produced.

Modify the text appropriately

Currently the text states that an importing domain that does not understand activity_specific_information encoded within the context (typically determined by looking at the type field) should simply null them out (or replace them with its own). I'd like to suggest that we change this so that the importing domain throws an exception, and does no work on behalf of that invocation. This is because typically this data will be dependant upon the specific extended transaction model in use, and an importing domain could corrupt data if it doesn't use the entire context correctly.

As per summary

The following section is taken from the Activity srevice specification
orbos/2000-06-19.
P48 "The Synchronization SignalSet has a similar role to that of
Synchronization objects within the OTS, i.e., it is invoked before and
after completion of the
Activity. Likewise, the completion status of an Activity may be changed by
the Actions registered with this SignalSet, such that the Activity?s
outcome when
postCompletion is called may be different to that when preCompletion was
invoked. If an Action error occurs during preCompletion (e.g., the
ActionError
exception is thrown) then the Activity completion status will be set to
CompletionStatusFailOnly."

In order for an Action itself to influence the completion status of an
Activity during signal processing, it must cause the SignalSet responsible
for the Signal being processed to set the appropriate completion status.
This is achieved through the Outcome the Action returns from the
process_signal call. In the case of the predefined SignalSets, no
predefined Outcomes are specified so there is no opportunity for an Action
processing the preCompletion signal to influence the completion status. The
object model for the Activity service does not encourage an Action to
invoke methods directly on a SignalSet (such as
SignalSet::set_completion_status) and Current::set_completion_status may
not be called after the completion SignalSet has started producing signals.
Therefore predefined Outcomes, that may be generated by Actions, are
required for the predefined SignalSets and the behaviour of these
predefined SignalSets, in terms of how they react to the predefined
Outcomes, needs to be specified. Per the specification, there is no need
for the predefined SignalSets themselves to produce an Outcome.

I propose the following predefined Outcomes: "org.omg.preCompletionSuccess"
and "org.omg.preCompletionFailed" that may be generated by Actions and
passed to the Synchronization SignalSet via the ActivityCoordinator calling
set_response. On receipt of the org.omg.preCompletionFailed Outcome during
preCompletion, the Synchronization SignalSet should set its completion
status to CompletionStatusFailOnly.

see above

The current draft of the Activity Service implicitly assumes a "presumed abort" type protocol, but doesn't mention it explicitly. The only reference an Action has to the activity it is involved with is the ActivityCoordinator it registered with. Now, if that coordinator is defunct (e.g., it failed before termination or simply decided to "abort" and couldn't get through to the Action because it had failed) when the Action calls get_status it will presumably get an OBJECT_NOT_EXIST exception. The Action should use this as an indication of a roll back, and act accordingly.

Add a Failure Assumptions subsection in the Implementor's View

In a distributed system consisting of:
client---------->server1

a client may perform:

CosActivity::Current_ptr cur;
cur->set_completion_status(CompletionStatusFail);
cur->set_completion_signal_set("CSS");
do some work - all is well
cur->complete_with_status(CompletionStatusSuccess);

The Activity service implementation of Current::complete_with_status needs
to propagate both CompletionSignalSet name and CompletionStatus to the
ActivityCoordinator. The means by which the Current object calls the
ActivityCoordinator is via the latter;s complete_activity method.
The signature for complete_activity allows the SignalSet name to be passed
but not the CompletionStatus.
I think at some point we had a set_completion_status method on the
ActivityCoordinator but it is no longer there.
There is currently no way for this information to be passed to the
ActivityCoordinator.

I believe the complete_activity method should take the CompletionStatus as
an additional parameter.

Modify the IDL and accompanying text

There has been a bit of discussion about the problems with implementing efficient interposition using global actions. The notion of global actions came about because it was originally thought that a downstream node would not need to have access to the same SignalSets that an upstream node had. However, although global actions make this possible, they make implementing efficient interposition very difficult. It also turns out that it makes more sense to require downstream nodes to have the same knowledge of the activity SignalSets as upstream.

So, what we're proposing is:

whenever an Action is registered with a SignalSet at a downstream node (A), that node must register a SubordinateSignalSet (see below) with the parent node (B). This need only be done once per SignalSet. It means that a downstream node is only informed about Signals that mean anything in it's context. Obviously B may be a downstream node to, say, Z, and as a result of having A register with it may then need to register an Action with A.

(ii) add a SubordinateSignalSet that derives from SignalSet and add the single method set_signal, which takes a Signal. A SignalSet is a finite-statemachine, and usually starts from point 0. set_signal lets it start (or re-start) from any point in the FSM. Whenever an interposed coordinator receives a Signal it passes it to the interposed signalset for that Signal using set_signal, and then uses the SignalSet as it would normally, i.e., calls get_signal, set_response etc. The interposed SignalSet can then collate the responses and send a single Outcome back. However, it can also do the local optimisations mentioned in an earlier email. So, for example, if a local Action responds with an outcome that can only mean the activity will rollback, rather than send that response back to B, A could do the local rollback on all registered participants first, saving B the time to send the next message.

This is covered by issue 4250, close issue

In order to implement the ChildLifetime SignalSet correctly we actually need two separate SignalSets (ChildLifetimeBegin, ChildLifetimeComplete), one for each of the two Signals. In addition, it is necessary that the activity is still active on the thread when childComplete is generated, in order that the actual activity identity can be encoded in the Signal. So, we need to reverse the order of the Synchronization and ChildLifetime SignalSets.

see above

If the destroy call on an Action fails then this should have no affect on the activity. This is simply used as a hint that the activity has completed, but an Action may decide to purge itself early if it wants to (the effect on the activity will obviously depend upon where in its life this occurs).

Clarify text.

In Section 2.2.5 of the specification, a number of pre-defined
PropertyGroupAttribute names and their associated values are described.
The following are also of value to better define the contract between
Activity service and PropertyGroup provider.

"marshal_response_update"
Indicates whether or not the PropertyGroupManager should be called when an
outbound response is marshalled. A value of "true" indicates that the
context for the managed PropertyGroup should be updated on a response. A
value of "false" indicates that the context for the managed PropertyGroup
is not updated on a response so the PropertyGroupManager is not called for
marshalResponse. The default value is "false" It may be preferable for
either a security or a performance point of view not to transmit server
context back to a client with a response.

"unmarshal_response_update"
Indicates whether or not the PropertyGroupManager should be called when an
inbound response is unmarshalled. A value of "true" indicates that the
context for the managed PropertyGroup should be updated by the response.
A value of "false" indicates that the context for the managed
PropertyGroup is not updated by the response so the PropertyGroupManager
is not called for unmarshalResponse. The default value is "false" It may
be preferable for either a security or a performance point of view not to
allow the local context to be updated by changes made in a downstream

Agree to the addition of more attributes.

There has always been an implicit assumption "something" knows when (and if)
to make references to Actions persistent during SignalSet processing. For
example, if we consider the case of a two-phase commit SignalSet, then once
prepare Signals have been sent and acknowledged successfully by Actions, the
service needs to make those references persistent (c.f. the transaction
service intentions list).

However, currently there is no way for this to happen. Only the Activity
Coordinator has the list of the Actions, but it doesn't (and shouldn't)
understand the semantics of the Signals it sends. The SignalSet understands
the semantics, but doesn't have a handle on the Actions. Somehow the
SignalSet must get hold of the Actions in order to do this.

What I propose is the addition of a set_coordinator method to SignalSet such
that when it is registered with the Activity Coordinator (or more likely
when it is about to be used) the coordinator can pass a reference to itself
through. Then the SignalSet can have access to the Action list. This is also
important if the SignalSet wants to make a one-phase optimisation (when
there is only a single Action, for example) as it needs to know the number
of Actions, not necessarily who they are.

see above

In order to write a portable application or application framework that uses
the Activity service, and in order for Activity service implementations to
fully interoperate, the ordering and semantics of completion processing
need to be more explictly defined than is presently the case.
I describe below what is intended and implied by the current specification,
but which I believe needs to be more explictly stated to avoid
implementations applying different interpretations.

1. Current::complete_with_status(cs) is called
2. This drives ActivityCoordinator::complete_activity(completion_ss_name,
cs). This may be a remote call and there is a separate issue as to whether
context is propagated on this; it depends on the ActivityPolicyValue of the
ActivityCoordinator.
3. The preComplete synchronization signal is distributed. Activity context
must be available on the thread when the Actions process this signal.
4. The completion signals are distributed to registered Actions. The
presence or not of Activity context with these flows is not defined. I
don't think the presence of Activity context hurts and is consistent with
the behaviour during synchronization preComplete. OTS is a little different
because Synchronization is a TO (OTSPolicy=ADAPTS) whereas Resource is not
(OTSPolicy=FORBIDS). One advantage of keeping the context available during
completion processing is that the PropertyGroups are available.
5. The childComplete processing occurs in any parent Activity. Logically,
the parent coordinator process_signal_set method is called and the
SignalSet implementation gets the information it needs from the current
Activity (which is the completing activity, still active on the thread) to
build the ActivityInformation structure.
6. The context is logically suspended. Any PropertyGroups are called with
suspended() and then with completed().
7. The postComplete synchronization signal is sent.
8. Any remaining Activity service objects for the completing Activity are
cleaned up.
9. The call returns to the client.

In some respects, it would be better if (5) and (6) could be reversed but
this cannot be the case if the child activity context needs to be on the
thread for the parent to perform the childComplete processing.

Change the text so it make things clearer

The Activity service specification states, in the description of
the SignalSet::set_response method:
"The SignalSet returns a boolean to indicate whether or not the
Action that returned the response should be informed of any further
signals from this signal set; if the value is true then the Action
continues to receive Signals."

This suggests that, if the SignalSet is used to broadcast signals
(rather than simply produce completion signals), an Action that
indicated it required no further signals during the first broadcast
within a particular Activity may well expect to receive signals if
the SignalSet was requested to broadcast a second time within the
same activity or indeed was subsequently asked to produce completion
signals.

In a subordinate node, there is no knowledge from one
process_signal(Signal) to the next as to which particular broadcast
the signal comes from. Therefore, the subordinate has no way of
knowing whether a registered Action that indicated no-further-signals
on a previous set_response should receive signals on subsequent
process_signal calls from the superior.

see above

Should an Activity service implementation be required to marshal a service
context when it sends a reply?
To put it another way, should a client Activity service interceptor expect
to receive context on a reply if it sent one on a request?

I would expect that absence of a context on a reply is fine but this needs
to be stated in the specification to ensure interoperability between
different vendors' implementations.

see above

The childComplete signal carries an ActivityInformation structure in its
application_specific_data field.
The ActivityInformation structure contains the GlobalId and final
CompletionStatus of the completed activity.
This structure also needs to contain the completed Activity's final Outcome
in order to be properly useful to application frameworks that need to know
about how a child activity completes.

closed no change

There is an implicit assumption in the current text that all Current objects
are available in all environments. This may not be the case, and we should
allow for the fact that some environments may wish to restrict the Currents
that are available.

see above