CICS® initiates a new alias transaction and a new program for each request made by a Web client. This is the case for pipelined requests, requests made using a persistent connection, and requests that form a logical sequence, as well as for individual standalone requests. You need to consider how the application's state will be managed between requests. If you need to share data across the request sequence, between different programs or instances of the same program, you can do this using CICS-managed resources, or using elements of the requests sent by the Web client.
You should design your application programs so that they can cope with delays or disruptions in the request sequence. For example, if you are sharing data across the request sequence, you should ensure the data is cleaned up if the request sequence does not complete or is delayed excessively. If your application programs update protected resources, you should ensure that updates that must be committed or backed out together are made in the same transaction. (This means that a single request from the Web client should be designed to complete the update.)
The ideal situation for an application is that each exchange of a request and response is self-contained and completes an independent element of the task. However, this design is not always possible, especially when the task is complex, or when a Web client has sent a pipelined sequence of requests. A pseudoconversational model may be required, where the application's state must be managed between requests. This can be arranged using the following techniques: