![]() | ![]() |
Home |
|
|
Access Service User's Guide DirectConnect for AS/400 |
|
| Chapter 5 Understanding the request process |
|
| Managing processing |
You can control processing by using configuration properties to determine the following:
How many rows are returned (MaxRowsReturned)
Whether to stop when an error occurs (StopCondition)
How to allocate conversations with a target AS/400 system (Allocate)
For more information about the preceding properties, see Chapter 2, "Configuring the DirectConnect Access Service Library"
To set values for properties in the configuration file, you must know the specific category the property belongs to, verify that the category exists in the file, and enter the property value under the category.
The MaxRowsReturned property specifies the maximum number of rows retrieved in a result set. (A result set is all or part of the results from a processed SQL statement.) However, one SQL request can produce multiple result sets.
If the number of rows exceeds the value of the MaxRowsReturned property, the access service returns the maximum number of rows and issues a warning message. However, the access service issues warning messages only when the SendWarningMessages property is enabled.
The StopCondition property specifies whether the access service stops processing a request when it encounters an error or a warning. Valid values are:
error
warning
none
If you specify none, processing continues even when errors occur. The StopCondition property is useful if you batch multiple statements in a request.
The Allocate property specifies when the APPC conversation that exists between the access service and the target database system is allocated and deallocated. Valid values are connect and request.
If you specify connect (the default), the APPC conversation remains active until the client issues some form of deallocation, such as an exit. As a result, fewer APPC connections are available, but overhead for each client is reduced.
If you specify request, resources are generally released quickly, so that more clients can access the target database concurrently. However, overhead increases because of the repeated initiation of APPC conversations for each request handled. You can specify request for either short or long transactions.
The tables on the following pages show how combined configuration property settings can affect processing results. The first two tables are based on the TransactionMode property settings of short and long. The third table shows processing behavior when a begin transaction statement occurs.
For your convenience, copies of these tables are also located in Appendix B, "Quick Reference."
The following four tables show the effects of combined StopCondition and Allocate properties, based on a TransactionMode setting of short.
The following table shows the effects of a TransactionMode property setting of short, an Allocate property of request and a StopCondition property of none.
Condition/Status | Effects of Settings on Processing |
Does a rollback occur on an error? | The transaction rolls back immediately. |
What is the status of connection after an error occurs? | The connection ends. |
What happens if a begin transaction occurs? | A commit occurs and uses begin transaction behavior described in Table 5-9. |
When the client application issues a commit or rollback, what happens? | A commit or rollback occurs. |
If the request is a cursor or dynamic request, how does it behave? | The request behaves the same as TransactionMode=long. |
In batch mode, what happens if an error occurs? | The batch ends and a rollback occurs. |
When completed, is a batch job committed? | The batch commits if no errors occur. |
After the batch commits, what is the status of the connection? | The connection ends. |
The following table shows the effects of a TransactionMode property setting of short, an Allocate property of request and a StopCondition property of none.
Condition/Status | Effects of Settings on Processing |
Does a rollback occur on an error? | A rollback does not occur. |
What is the status of the connection after an error occurs? | The connection continues. |
What happens if a begin transaction occurs? | A commit occurs and uses begin transaction behavior described in Table 5-9. |
When the client application issues a commit or rollback, what happens? | A commit or rollback occurs. |
If the request is a cursor or dynamic request, how does it behave? | The request behaves the same as TransactionMode=long. |
In batch mode, what happens if an error occurs? | The batch continues executing. |
When completed, is a batch job committed? | The batch is always committed. |
After the batch commits, what is the status of the connection? | The connection ends. |
The following table shows the effects of a TransactionMode property setting of short, an Allocate property of connect and a StopCondition property of error.
Condition/Status | Effects of Settings on Processing |
Does a rollback occur on an error? | The transaction rolls back immediately. |
What is the status of the connection after an error occurs? | The connection continues. |
What happens if a begin transaction occurs? | A commit occurs and uses begin transaction behavior described in Table 5-9. |
When the client application issues a commit or rollback, what happens? | A commit or rollback occurs. |
If the request is a cursor or dynamic request, how does it behave? | The request behaves the same as TransactionMode=long. |
While in batch, what happens if an error occurs? |