Database transactions allow your application to make a series of database changes in an all-or-nothing commit. Consider an HTTP request that creates a new Order and has an afterChange
hook to update the stock count of related Items. If an error occurs when updating an Item and an HTTP error is returned to the user, you would not want the new Order to be persisted or any other items to be changed either. This kind of interaction with the database is handled seamlessly with transactions.
By default, Payload will use transactions for all operations, as long as it is supported by the configured database. Database changes are contained within all Payload operations and any errors thrown will result in all changes being rolled back without being committed. When transactions are not supported by the database, Payload will continue to operate as expected without them.
The initial request made to Payload will begin a new transaction and attach it to the req.transactionID
. If you have a hook
that interacts with the database, you can opt-in to using the same transaction by passing the req
in the arguments. For example:
Since Payload hooks can be async and be written to not await the result, it is possible to have an incorrect success response returned on a request that is rolled back. If you have a hook where you do not await
the result, then you should not pass the req.transactionID
.
When writing your own scripts or custom endpoints, you may wish to have direct control over transactions. This is useful for interacting with your database in something like a background job, outside the normal request-response flow.
The following functions can be used for managing transactions:
payload.db.beginTransaction
- Starts a new session and returns a transaction ID for use in other Payload Local API calls. Note that if your database does not support transactions, this will return null
.
payload.db.commitTransaction
- Takes the identifier for the transaction, finalizes any changes.
payload.db.rollbackTransaction
- Takes the identifier for the transaction, discards any changes.
You can then use the transaction ID with Payload's local API by passing it inside the PayloadRequest
object.
Here is an example for a "background job" function, which utilizes the direct transaction API to make sure it either succeeds completely or gets rolled back in case of an error.