Transferring data to asynchronous activations

There are a number of ways in which your applications can handle the transfer of data to and from activities that are run asynchronously with the requestor. In the simplest case, a single data-container can be used for both input and output data. If the activity is activated only once, this activation presents no problems. Separate containers are used, one for input and one for output data. Again, if the activity is activated only once, this presents no problems. However, if the activity might be activated, asynchronously, multiple times, you must take care that the contents of containers are not overwritten inadvertently. You must take particular care when designing client/server applications, and applications which involve activities being acquired and run multiple times by transactions external to their parent process.

If an application chooses to run a server process or an acquired activity asynchronously, it needs to be aware of the state of the activity being activated. In most cases, the activity is dormant - awaiting the activation and ready to perform its function. The activation occurs almost immediately, the activity program runs, and places any results in a container. In a client/server application, the activity might then be left dormant, ready for the next request. If the activation is triggered by an external interaction, it is likely that the activity will complete; the firing of its completion event causes its parent to be activated again.

However, you must consider that, when the RUN ASYNCHRONOUS command is executed, the target activity might not be dormant, waiting for work - it might be in any of the other possible processing modes, or it could be suspended. If, for example, the target activity has been suspended, the asynchronous activation does not happen immediately. Thus, in a client/server application, it is possible for the client program to issue a request to the server before a previous request has been serviced. You should be aware of these possibilities when designing your applications. If, for example, the protocol between a client program and its server activity relies on a single container for passing data, the client needs to check that the container is not occupied by a previous request before issuing subsequent requests. Another solution is for the client to use multiple containers to form a queue of requests for the server activity; the containers could be named sequentially.