COMMIT MODE
This field is used to define or change the COMMIT MODE of any process. COMMIT MODE determines those points in time when APPX will commit changes made to the tables stored within an RDBMS. It is only applicable in conjunction with an RDBMS; it cannot be used with APPXIO. Also, not all File Managers support this feature.
This field can be set in the Additional Attributes of all processes but can be added or overridden by use of this field. Note that when COMMIT MODE is changed via a SET statement, the change takes effect at the next COMMIT or ROLLBACK statement.
SET --- COMMIT MODE = COMPATIBLE
Valid Values:
|
COMPATIBLE |
Changes are committed as soon as all logical locks are freed. This provides maximum compatibility between APPXIO files and RDBMS tables. Note that both APPXIO and RDBMS locks must be released. |
|
AUTOCOMMIT* |
Commit each modification as
it is made. |
|
PCF CYCLE |
Commit modifications as each PCF record is processed, normally after the Post PCF Update event point. |
|
END |
Only commit modifications at the end of the process family. |
|
MANUAL |
Modifications must be committed manually via use of the COMMIT statement. APPX will not automatically COMMIT any changes. |
COMPATIBLE is the default value while use of AUTOCOMMIT, when implemented, is the least effective in terms of performance.
Based on the structure of your application, there may be other places where you want to COMMIT a transaction. That's what the COMMIT statement is for. One thing to keep in mind is that the frequency of COMMITs will affect performance. The more COMMITs you do, the slower your application will be. For interactive processes, you can probably ignore the performance issue, but for batch-mode operations, COMMITing too often can really slow things down.
Another issue to be aware of is that APPXIO files do not support transaction processing. If you ROLLBACK a change to an RDBMS-hosted file, any changes made to APPXIO will not be rolled back. Related to this is the issue of visibility. Changes made to an RDBMS-hosted file are invisible to other users until they are committed. Changes made to an APPXIO-hosted file are visible immediately.
APPX also supports savepoints. A savepoint is a partial transaction. You mark the beginning of a savepoint with the SAVEPNT statement - the only argument is a name of your choosing. Executing a SAVEPNT tells the RDBMS that it should write a marker into the current transaction. If you find that you want to roll back part of a transaction, you can refer to a savepoint name in the ROLLBACK statement. The transaction is still open and you can commit other changes, but changes made since the savepoint was created are discarded.
If using COMPATIBLE mode, it is helpful to understand when locks are applied and released. When you read an RDBMS record with hold, you obtain a physical lock and a logical lock. As soon as you delete that record, rewrite it, or read another record, the logical lock is forfeited, but the physical lock is held until the transaction is committed (or rolled back). The physical lock may, depending on the database, prevent other users from reading the record, or it may prevent other users from locking the record. APPXIO, on the other hand, releases the physical lock at the same time as the logical lock. In COMPATIBLE mode, APPX commits changes as soon your task releases all the logical locks, both APPXIO and RDBMS.
Related Statements