Transactions
Table of Contents
# Introduction
We already discussed the Mongock process and the migration component in previous sections where the transactions are already mentioned.
As its name suggests, a changeUnit represents the unit of a migration. By default each changeUnit is wrapped in a independent transaction. This can be change by configuration, but it's not recommended.
In this section we mention native transactions. By this we mean the transaction mechanism provided by the database.
Mongock always try to provide a transactional environment as much as possible. When native transactions are not possible, it tries to rollback the changes manually with the @RollbackExecution method.
# Configuration
As of Mongock release 5.5, mongock.transactionEnabled property is deprecated in favour of new mongock.transactional property. Note that is not compatible to use both of them. In a future release mongock.transactionEnabled will be removed.
There are two points where the transactions are configured to be enforced or disabled, the property mongock.transactional
(setTransactional method in the builder) and the driver.
In every driver's page, you will find enough information about how to enable the native transactions.
As explained in the runner properties table, the Mongock native transactionability follows the next logic:
When mongock.transactional is true, it enforces native transactions, throwing an exception is the driver is not capable of it.
When mongock.transactional is false, it disables the transactions and ignores the transactionability of the driver.
When mongock.transactional is null, it totally delegates on the driver the transactionability of the migration.
# How it works
The easiest way to understand how Mongock handles the transactions is by looking at this section.
# Best practices
- Always set explicitly the
mongock.transactional
property to true/false. - DDL operations placed in the @BeforeExecution method of the changeUnit.