While processing a web request, the OutSystems Platform begins a database transaction on its first access to the database. The transaction is committed before the Platform sends the response to the user.

If an exception is left uncaught, the transaction is rolled back. This means that changes made to the database within the transaction are all reverted, this way ensuring that your data remains consistent.

Ending Transactions Explicitly

You can manage transactions explicitly through the CommitTransaction and AbortTransaction actions:

Isolation Levels

The following table shows the isolation level OutSystem Platform uses in the different databases:





SQL Server

Isolation level

Read Committed

Read Uncommitted

Read Committed

Read Uncommitted

When using a MySQL or SQL Server database, you are working at Read Uncommitted isolation level. You have multiple transactions per web request: one for writes, one for each read.

When using a DB2 or Oracle database, you are working at Read Committed isolation level. All queries, inserts, updates, etc. happen in the same database transaction. The data is stored to the database only when the transaction is committed.
This means that you are not able to read data that was not yet committed in a transaction. Because of this, before you call a Process instance or a method of a consumed Web Service, you need to commit the database transaction, to see up-to-date data in the process or method.

Important Remarks

There are some aspects concerning transactions that you should pay attention to, namely:

See Also

Commit Transaction Action | Abort Transaction Action | Handling Transactions with External Systems