logo_smallAxellero.io

Transaction

Manage database transaction boundaries with atomic commit and rollback operations for data consistency.

Transaction

Control database transaction boundaries to ensure atomic operations and data consistency across multiple database operations. Used for maintaining data integrity in workflows involving multiple database modifications.

Quick Navigation

Configuration

Inputs

NameCodeTypeRequiredDescription
Is RollbackisRollbackBooleanNoWhether to rollback the transaction (default: false)
Transaction IDtxIdTextConditionalTransaction identifier for specific transaction control

💡 Transaction Scope

Transactions automatically span across all database operations within a workflow execution unless explicitly committed or rolled back.

Outputs

NameTypeDescription
stateTextTransaction result: "ok", "error", or "skipped"

Transaction Control

Available Operations

OperationPurposeUse CaseSafety Level
CommitPermanently save changesComplete successful operations✅ Safe
RollbackRevert all changesHandle errors and inconsistencies🔄 Recovery
Auto-commitDefault behaviorSimple single-operation workflows⚠️ Limited

Transaction Lifecycle

Transaction Patterns

Integration Examples

Complete Transactional Workflows

Integration Pattern

Transactions work with database operations and external system integrations requiring atomicity.

Transaction States & Error Handling

State Management

StateDescriptionNext Actions
okTransaction completed successfullyContinue workflow
errorTransaction operation failedHandle error, retry if appropriate
skippedNo active transaction foundCheck transaction scope

Error Handling Patterns

Best Practices

Best Practices

  1. Keep transactions short to minimize lock contention
  2. Validate data early before starting expensive operations
  3. Use explicit rollbacks for complex error scenarios
  4. Monitor transaction scope to ensure proper boundaries
  5. Implement retry logic for transient failures
  6. Log transaction decisions for audit and debugging

Performance Considerations

⚠️ Performance Notes

  • Long transactions can cause database locks and performance issues
  • Nested transactions are not supported - use single transaction scope
  • Concurrent workflows may experience lock contention on shared resources
  • Large batch operations should be chunked to avoid timeout issues

Security Guidelines

Security AspectRecommendationImplementation
Transaction IsolationUse appropriate isolation levelsConfigure at database level
Audit LoggingLog all transaction decisionsInclude user context and timestamps
Error DisclosureLimit error information exposureUse generic error messages in API responses
Permission CheckingValidate permissions before transactionsCheck ctx.user.roles before database operations

Common Anti-Patterns

Anti-Patterns

  • Long-running transactions spanning user interactions
  • Transactions without error handling leading to inconsistent state
  • Ignoring transaction state in subsequent workflow logic
  • Manual transaction management when auto-commit would suffice
  • File operations within database transactions without proper cleanup

Troubleshooting

Common Issues

ProblemSymptomsSolution
Transaction state 'skipped'No active transaction to commitVerify database operations are within transaction scope
Deadlock errorsConcurrent transactions failImplement retry logic with exponential backoff
Partial rollbackSome changes persist after rollbackCheck transaction boundaries and nested operation scope
Performance degradationSlow database operationsReduce transaction scope and duration

Next: Explore File Storage for coordinating file operations with transactions, or learn about Data Converter for processing data before storage operations.