Skip to main content
The @transactional decorator wraps methods in a database transaction to ensure data consistency.

Basic Usage

Options

isolation

Specifies the transaction isolation level.
Default: Database default isolation level (PostgreSQL: read committed)
read uncommitted (Lowest)
  • Can read uncommitted data
  • Dirty reads possible
  • Fastest but risky
read committed (Default)
  • Only reads committed data
  • Prevents dirty reads
  • Non-repeatable reads possible
repeatable read
  • Same data always returns same value within transaction
  • Prevents non-repeatable reads
  • Phantom reads possible
serializable (Highest)
  • Transactions behave as if executed serially
  • Prevents all anomalies
  • Safest but slowest

readOnly

Sets the transaction as read-only. Default: false
Using readOnly: true allows the database to perform optimizations, potentially improving performance.

dbPreset

Specifies the database preset to use. Default: "w" (Write DB)

Complete Options Example

How Transactions Work

Automatic Commit/Rollback

Transaction Nesting

Transactions with the same dbPreset are reused:
Log Output:

Different Preset Transactions

Different dbPresets create separate transactions:

Using with Other Decorators

With @api

Order matters: Write @api first, then @transactional.

With @cache

With @upload

AsyncLocalStorage

@transactional uses Node.js’s AsyncLocalStorage to manage transaction context.

Context Creation

Context Reuse

Error Handling

Automatic Rollback

Manual Rollback

Throw an error when explicit rollback is needed:

Precautions

1. Only Available in BaseModelClass

2. Beware of Long Transactions

3. Beware of External API Calls

Logging

The @transactional decorator automatically logs:

Examples

Next Steps

@api

Create API endpoints

@upload

Create file upload APIs

Database Guide

Use Puri query builder

Error Handling

Learn error handling methods