Skip to main content

Commit Transaction

Commits a transaction and applies all pending changes to the BadgerDB database atomically.

Common Properties​

  • Name - The custom name of the node.
  • Color - The custom color of the node.
  • Delay Before (sec) - Waits in seconds before executing the node.
  • Delay After (sec) - Waits in seconds after executing node.
  • Continue On Error - Automation will continue regardless of any error. The default value is false.
info

If the ContinueOnError property is true, no error is caught when the project is executed, even if a Catch node is used.

Inputs​

  • Transaction Id - The unique identifier of the transaction to commit, as returned by the Start Transaction node.

How It Works​

The Commit Transaction node finalizes a transaction, making all buffered changes permanent in the database.

When executed, the node:

  1. Validates the transaction ID
  2. Retrieves the transaction instance
  3. Commits all pending changes atomically
  4. Removes the transaction from the active transaction pool
  5. Ensures all changes are persisted to disk
info

All changes made within the transaction are applied together. If commit fails, no changes are applied.

Examples​

Example 1: Basic Transaction Commit​

Commit changes after multiple operations:

1. Start Transaction
   Database Id: {{db_id}}
   → txn_id

2. Set User Name
   Database Id: {{db_id}}
   Transaction Id: {{txn_id}}
   Key: user:1001:name
   Value: "John Doe"

3. Set User Email
   Database Id: {{db_id}}
   Transaction Id: {{txn_id}}
   Key: user:1001:email
   Value: "john@example.com"

4. Commit Transaction
   Transaction Id: {{txn_id}}

Example 2: Conditional Commit​

Only commit if conditions are met:

1. Start Transaction
   Database Id: {{db_id}}
   → txn_id

2. Get Balance
   Database Id: {{db_id}}
   Transaction Id: {{txn_id}}
   Key: account:balance
   → balance

3. If {{balance}} >= 100:
   Set New Balance
     Database Id: {{db_id}}
     Transaction Id: {{txn_id}}
     Key: account:balance
     Value: {{balance - 100}}

   Commit Transaction
     Transaction Id: {{txn_id}}

   Log "Payment successful"
Else:
   Log "Insufficient funds"
   (Transaction not committed, changes discarded)

Example 3: Error Handling with Commit​

Use try-catch to handle commit errors:

Try:
  1. Start Transaction
     Database Id: {{db_id}}
     → txn_id

  2. Perform multiple operations...
     Transaction Id: {{txn_id}}

  3. Commit Transaction
     Transaction Id: {{txn_id}}

  Log "Transaction committed successfully"

Catch:
  Log "Transaction failed: {{error}}"
  (Transaction auto-discarded on error)

Example 4: Batch Update​

Commit batch operations:

1. Start Transaction
   Database Id: {{db_id}}
   → txn_id

2. For each user in {{user_list}}:
   Set User Status
     Database Id: {{db_id}}
     Transaction Id: {{txn_id}}
     Key: user:{{user.id}}:status
     Value: "active"

3. Commit Transaction
   Transaction Id: {{txn_id}}

Log "Updated {{user_list.length}} users"

Example 5: Multi-Step Process​

Commit after validation:

1. Start Transaction
   Database Id: {{db_id}}
   → txn_id

2. Get Current Value
   Database Id: {{db_id}}
   Transaction Id: {{txn_id}}
   Key: config:version
   → version

3. Validate Version
   If {{version}} == expected_version:
     Set New Configuration
       Database Id: {{db_id}}
       Transaction Id: {{txn_id}}
       Key: config:settings
       Value: {{new_settings}}

     Set New Version
       Database Id: {{db_id}}
       Transaction Id: {{txn_id}}
       Key: config:version
       Value: {{version + 1}}

     Commit Transaction
       Transaction Id: {{txn_id}}
   Else:
     Log "Version mismatch"
     (Transaction discarded)

Tips for Effective Use​

  • Always Pair with Start Transaction - Every Start Transaction should have a Commit
  • Commit at the End - Place Commit Transaction after all operations
  • Handle Commit Errors - Use try-catch blocks to handle commit failures
  • Validate Before Commit - Check conditions before committing
  • One Commit Per Transaction - Each transaction should be committed only once
  • Document Commit Points - Add comments explaining why changes are being committed

Common Errors and Solutions​

Error: "Transaction Id cannot be empty"​

Solution: Ensure you're passing the transaction ID from Start Transaction.

Correct:
  Start Transaction → txn_id
  ... operations ...
  Commit Transaction (Transaction Id: {{txn_id}})

Error: Transaction Not Found​

Solution: The transaction may have already been committed or discarded. Ensure:

  • Start Transaction was successful
  • Transaction ID is correct
  • Transaction hasn't already been committed
  • Transaction wasn't discarded due to an error

Error: Commit Conflict​

Solution: Another transaction modified the same keys. Options:

  1. Retry Pattern:
Set max_retries = 3
Set attempt = 0

While {{attempt}} < {{max_retries}}:
  Try:
    Start Transaction → txn_id
    Perform operations...
    Commit Transaction
    Break (success)
  Catch:
    attempt = {{attempt + 1}}
    If {{attempt}} >= {{max_retries}}:
      Log "Transaction failed after retries"
  1. Optimistic Locking:
Start Transaction → txn_id
Get version → current_version
If {{current_version}} == {{expected_version}}:
  Update data
  Increment version
  Commit Transaction
Else:
  Log "Conflict detected"

Error: Disk Space Full​

Solution: Ensure sufficient disk space for the commit.

  • Free up disk space
  • Clean up old data
  • Monitor disk usage

Commit Guarantees​

Atomicity​

  • All changes in the transaction are applied together
  • If commit fails, no changes are applied
  • Database remains in a consistent state

Durability​

  • Once committed, changes are permanent
  • Survives system crashes and restarts
  • Changes are synced to disk

Isolation​

  • Committed changes become visible to other transactions
  • Before commit, changes are invisible to others
  • No partial updates visible

Transaction States​

Before Commit​

  • Changes buffered in memory
  • Not visible to other transactions
  • Can be discarded without affecting database

During Commit​

  • Changes being written to disk
  • Database locked for affected keys
  • Conflict detection performed

After Commit​

  • Changes permanent and visible
  • Transaction removed from active pool
  • Resources released

Performance Considerations​

  • Commit Overhead - Commits require disk sync (relatively slow)
  • Batch Commits - Committing many operations together is efficient
  • Commit Frequency - Balance between atomicity needs and performance
  • Disk Speed - Commit speed depends on disk performance
  • Memory Usage - Large transactions buffer more data before commit

Best Practices​

  • Explicit Commits - Always explicitly commit transactions
  • Error Handling - Wrap commit in try-catch blocks
  • Short Transactions - Commit as soon as operations complete
  • Validation Before Commit - Validate data before committing
  • Log Commits - Log successful commits for audit trail
  • Test Rollback - Test that failed commits don't corrupt data
  • Monitor Commit Times - Track commit duration for performance

Commit Patterns​

Pattern 1: Simple Commit​

Start Transaction → txn_id
Operations...
Commit Transaction

Pattern 2: Conditional Commit​

Start Transaction → txn_id
Operations...
If validation_passed:
  Commit Transaction
Else:
  (Don't commit, transaction discarded)

Pattern 3: Commit with Retry​

For retry in range(max_retries):
  Try:
    Start Transaction → txn_id
    Operations...
    Commit Transaction
    Break
  Catch:
    If retry == max_retries - 1:
      Throw error

Pattern 4: Commit with Logging​

Start Transaction → txn_id
Operations...
Try:
  Commit Transaction
  Log "Committed: {{transaction_description}}"
Catch:
  Log "Commit failed: {{error}}"
  Throw error

When Commit Fails​

If Commit Transaction fails:

  • All changes in the transaction are discarded
  • Database remains in the state before the transaction started
  • Transaction is removed from active pool
  • Error is thrown to the flow

Auto-Discard vs. Explicit Commit​

Auto-Discard (No Commit Called)​

  • Transaction ends when flow completes
  • All changes are discarded
  • No changes applied to database

Explicit Commit​

  • Changes are applied atomically
  • Transaction is explicitly finalized
  • Changes are permanent

Always call Commit Transaction to apply changes!

  • Start Transaction - Starts a transaction
  • Get - Reads values within transaction
  • Set - Writes values within transaction
  • Delete - Deletes keys within transaction