13.12.1 Using Mixed Mode Commitment Control
Enabling Mixed Mode Commitment Control allows Visual LANSA applications to emulate IBM i commitment control, so that if some files are under commitment control and other files are not under commitment control, the application behavior will closely emulate the behavior on an IBM i.
By default, the SQL/ODBC COMMIT issued for files not under commitment control after each I/O command also commits files under 13.12 Commitment Control, as a single database connection is used for updates to both kinds of files. When Mixed Mode Commitment Control is enabled, separate database connections are used to manage the two sets of files, so files under commitment control are only committed by an explicit COMMIT.
To enable Mixed Mode Commitment control, add the line "MIXED_MODE_COMMITMENT=YES" to the X_DBMENV.DAT file on the system where the OAMs are executed, under the appropriate database type. Refer to X_DBMENV.DAT in the for further information. For example :
DATABASE_TYPE=MSSQLS
DATABASE_DESCRIPTION=Microsoft SQL Server
...
MIXED_MODE_COMMITMENT=YES
If this line is not present exactly as shown then the new feature will not be enabled and all I/O commands will continue to function as they did before.
Changes to the MIXED_MODE_COMMITMENT setting are immediate. No regeneration or recompilation of applications is required when the MIXED_MODE_COMMITMENT setting for an environment is changed.
This feature may not be useable with the database SYNC_POINT optimization facility. Refer to SET_SESSION_VALUE in the for information. LANSA therefore recommends these features are not used together.
Enabling Mixed Mode Commitment for the main database type also enables the feature for I/O operations to PC Other Files, regardless of their actual database type. Thus, if DBUT=MSSQLS and MIXED_MODE_COMMITMENT=YES has been specified for MSSQLS, any PC Other Files will also have mixed mode commitment enabled.
Batch control operations will be committed (or rolled back) in the same way that operations to their associated "owner" file are. Thus if file ITEM (that is, the "owner" file) has batch control logic associated with it that updates file ORDER, then the batch control updates/inserts to the ORDER file :
- Will use the same database connection as is currently being used to update the ITEM file.
- Will never be themselves committed. Commitments to the ORDER file are actually done (or not done) according to the rules effecting the "owner" ITEM file. If the ITEM file commits then the ORDER batch controls commit, if the ITEM file does not commit, then neither do the ORDER batch controls.