configuring-transaction-isolation

Transaction isolation levels prevent race conditions by controlling how concurrent transactions interact. In Prisma, use `prisma.$transaction()` with isolation levels like Serializable, RepeatableRead, or ReadCommitted to enforce consistency guarantees that block dirty reads, phantom reads, and lost updates in financial transfers, inventory management, and booking systems.

Serializable offers the strictest consistency, treating concurrent transactions as if they ran sequentially; RepeatableRead prevents phantom reads and non-repeatable reads with moderate overhead; ReadCommitted provides weaker guarantees but better performance. Choose based on your consistency requirements and tolerance for concurrency trade-offs.

P2034 errors occur when transaction isolation conflicts arise. Implement retry logic around your `prisma.$transaction()` calls to automatically re-execute the transaction when conflicts are detected, allowing the operation to succeed under less contention.

Transaction isolation is appropriate for critical paths where multiple concurrent updates could cause anomalies—financial operations, inventory decrement, and booking reservations. Database-enforced isolation is simpler than application locking and guarantees consistency even across server restarts.

Yes. Each `prisma.$transaction()` call accepts its own isolation level via `TransactionIsolationLevel`, letting you use Serializable for critical operations and ReadCommitted for less sensitive queries to balance consistency and performance within a single application.