Official Content

GeneXus offers this property for each transaction and for each procedure in order to define if you wish the generated program perform an automatic COMMIT or not.

Values

Yes The generated program executes a commit at the end of the Logical Unit of Work (LUW). This is the default value.
No The generated program does not execute a commit at the end of the Logical Unit of Work (LUW).

 

Description

GeneXus by default, includes a COMMIT sentence in the generated programs associated to transaction and procedure objects:

  • In procedures: an automatic COMMIT is included in the generated program, at the end of the source.
  • In transactions: an automatic COMMIT is included in the generated program, after modifying (insertion, update or deletion) each instance of data in the database, immediately before executing the code associated to rules that contain the AfterComplete Triggering event. For example, if 5 invoices are inserted through a 2 level transaction, the COMMIT will be executed 5 times, after each invoice is complete stored and before the execution of the rules that have the AfterComplete triggering event.

What reasons could there be for not performing a COMMIT in a transaction or procedure?

To personalize a  Logical Unit of Work (LUW). That is, we may need to expand a Logical Unit of Work (LUW) so that for example, several procedures (or 1 transaction with 1 -or several- procedures) make up a single Logical Unit of Work (LUW).

Example

Let's suppose the “X” transaction invokes the “Y” procedure and we want both objects to make up a single LWU. The transaction updates certain records, the procedure updates other records, and we want that the whole set of operations make up a single LUW to guarantee that, if a failure occurs, either the whole set of updates is performed in the database or any update is performed at all.

To achieve this, we can remove the COMMIT from the procedure and choose to perform it in the transaction (when returning from the procedure to the transaction); therefore, we would set the value of the procedure's Commit on Exit property to No and we would leave the transaction's Commit on Exit property set to Yes (the default value). 

CommitOnExitValueNo

But, in addition, it is vital to call the procedure before the COMMIT is performed in the transaction (since both objects should make up a single LUW). So, the COMMIT must be performed in the transaction when returning from the procedure; therefore, the invocation to the procedure must be defined in the transaction, with a triggering event occurring before the COMMIT (depending on the requirements and whether it is a single-level or multi-level transaction, the triggering event could be: AfterInsert,  AfterUpdate, AfterLevel Level 2ndLevel Attribute or BeforeComplete, but not AfterComplete).

There isn't a single way for personalizing a LWU. The important thing is to analyze which object will perform the COMMIT (there could be more than one possibility) and once the object has been chosen, it's important to determine an appropriate moment for the invocation, depending on whether the COMMIT will be performed.

Important restriction

In web environments, each transaction can commit only the set of operations made to the database by that transaction (and by the called procedures by it), but not the operations made by another transaction. That is, if a transaction calls another transaction, the Commit performed by one of them does not apply to the records inserted/modified/deleted by the other one; therefore, two different transactions cannot be included in the same LUW.

If you need to perform operations through two different transactions and you want them to make up a single LUW, the solution you have is to execute the transactions using the Business Component concept and include the Commit command after performing all the operations associated to both transactions.

 

Notes

This property is ignored if any of the following points are true:

  1. Transactions having the Disabled value for the Commitment property when the environment supports it. RPG and Cobol for iSeries generators are an example.
  2. Transaction used as Business Component. It means, in spite of having in a transaction its Commit on exit property = Yes, if you use that transaction as business component, the commit will not be automatically performed; on the other hand, you must execute the commit command explicitly. The reason for this is to allow you to make up a specific LUW between multiple transactions, including the commit command where you consider.
     

Scope

Objects Procedure object, Transaction object
Languages .NET, Java, Ruby, Visual FoxPro
   

 




Last update: February 2024 | © GeneXus. All rights reserved. GeneXus Powered by Globant