NonStop SOAP User's Manual

NonStop SOAP Features and Functions
NonStop SOAP User’s Manual—520501-012
4-15
Transaction Management
Transaction Management
A transaction is a series of requests that are valid only as a unit: if any request in the
series fails, the effects of earlier requests must be undone, or rolled back, usually to
ensure database consistency.
On a NonStop system transaction management is a function of TMF. That product is
required to be installed and running if you wish to use the transaction management
features of NonStop SOAP.
Using NonStop SOAP, a client can start a transaction, then issue multiple, serialized,
requests to a SOAP server. The SOAP server manages the transaction on behalf of
the client, ending the transaction in response to a client request or certain other
conditions.
NonStop SOAP supports transactions only with target services that can inherit a
transaction ID from the SOAP server. A service that does not inherit this transaction ID
cannot roll back a transaction in response to an abort request from the server.
A transaction must occur within a session. Multiple transactions can occur, one after
another, within the same session, provided that the target service supports multiple
transactions in a session. (For example, some context-sensitive TS/MP services are
limited to one transaction per dialog.) NonStop SOAP does not support concurrent
transactions within the same session, but if multiple sessions are in progress
concurrently, a SOAP server can manage multiple transactions, one per session, as
follows:
1. The SOAP server begins a transaction in response to a client’s request. A
transaction can be established only if the service supports transactions, as
reflected in the definition of the service in the SDL file.
2. After performing a request within a transaction boundary, the server suspends the
transaction (unless the request included a command to end the session, in which
case the server commits or aborts the transaction).
3. Upon receiving a subsequent request with the same session ID, the server
resumes the transaction, provided that the target service supports transactions. If
the target service does not support transactions, the request is processed but is
not included in the transaction.
4. Upon receiving a request with a different session ID, the server processes the
request within the transaction boundary that applies to that session.
5. The SOAP server commits or aborts a transaction in response to a client’s request.
6. After a transaction is committed or aborted, the client can request to start a new
transaction within the session.
Example 9: Level 2 Trace on page 6-69 illustrates the behavior of the SOAP server in
response to a series of requests within the scope of a transaction.