Skip to main content

Start Transaction

Starts a new transaction for performing atomic read and write operations on a BadgerDB database.

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​

  • Database Id - The unique identifier of the database, as returned by the Open node.

Output​

  • Transaction Id - A unique identifier for the started transaction. Use this ID in Get, Set, and Delete nodes to perform operations within the transaction.

How It Works​

The Start Transaction node creates a new transaction context that allows multiple database operations to be grouped together and committed atomically.

When executed, the node:

  1. Validates the database ID
  2. Creates a new read-write transaction
  3. Returns a unique transaction ID
  4. Keeps the transaction active until committed or the flow ends

Transaction Basics​

ACID Properties​

Transactions in BadgerDB provide:

  • Atomicity - All operations succeed or all fail together
  • Consistency - Database remains in valid state
  • Isolation - Operations are isolated from other transactions
  • Durability - Committed changes are permanent

Transaction Lifecycle​

  1. Start Transaction - Begin transaction
  2. Operations - Perform Get, Set, Delete operations
  3. Commit Transaction - Apply all changes atomically
  4. OR Flow ends - Transaction auto-discarded if not committed

Examples​

Example 1: Basic Transaction​

Update multiple related values atomically:

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

2. Set Balance
   Database Id: {{db_id}}
   Transaction Id: {{txn_id}}
   Key: account:1001:balance
   Value: 5000.00
   Encoding: Float

3. Set Status
   Database Id: {{db_id}}
   Transaction Id: {{txn_id}}
   Key: account:1001:status
   Value: "active"
   Encoding: String

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

Example 2: Bank Transfer​

Transfer money between accounts atomically:

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

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

3. Get Destination Balance
   Database Id: {{db_id}}
   Transaction Id: {{txn_id}}
   Key: account:1002:balance
   → dest_balance

4. Calculate New Balances
   new_source = {{source_balance}} - 100
   new_dest = {{dest_balance}} + 100

5. If {{new_source}} >= 0:
   Set Source Balance
     Database Id: {{db_id}}
     Transaction Id: {{txn_id}}
     Key: account:1001:balance
     Value: {{new_source}}

   Set Destination Balance
     Database Id: {{db_id}}
     Transaction Id: {{txn_id}}
     Key: account:1002:balance
     Value: {{new_dest}}

   Commit Transaction
     Transaction Id: {{txn_id}}
Else:
   Log "Insufficient funds"
   (Transaction auto-discarded)

Example 3: Conditional Update​

Update only if condition is met:

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

2. Get Counter
   Database Id: {{db_id}}
   Transaction Id: {{txn_id}}
   Key: request_counter
   → counter

3. If {{counter}} < 1000:
   Set Counter
     Database Id: {{db_id}}
     Transaction Id: {{txn_id}}
     Key: request_counter
     Value: {{counter + 1}}

   Commit Transaction
     Transaction Id: {{txn_id}}
Else:
   Log "Limit reached"
   (Transaction auto-discarded)

Example 4: Batch Delete​

Delete multiple related keys atomically:

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

2. Delete User Profile
   Database Id: {{db_id}}
   Transaction Id: {{txn_id}}
   Key: user:12345:profile

3. Delete User Settings
   Database Id: {{db_id}}
   Transaction Id: {{txn_id}}
   Key: user:12345:settings

4. Delete User Sessions
   Database Id: {{db_id}}
   Transaction Id: {{txn_id}}
   Key: user:12345:sessions

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

Example 5: Read Consistency​

Read multiple related values consistently:

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

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

3. Get Account Status
   Database Id: {{db_id}}
   Transaction Id: {{txn_id}}
   Key: account:status
   → status

4. Get Account Updated Time
   Database Id: {{db_id}}
   Transaction Id: {{txn_id}}
   Key: account:updated
   → updated

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

(All reads see the same consistent snapshot)

Tips for Effective Use​

  • Use for Related Operations - Group operations that must succeed or fail together
  • Keep Transactions Short - Long-running transactions can impact performance
  • Always Commit - Remember to call Commit Transaction to apply changes
  • Handle Errors - Use try-catch to handle transaction errors
  • Read Consistency - Use transactions to read multiple values consistently
  • Atomic Updates - Update multiple keys atomically to maintain consistency

Common Errors and Solutions​

Error: "database id cannot be empty"​

Solution: Ensure you're passing a valid database ID from the Open node.

Correct:
  Open → db_id
  Start Transaction (Database Id: {{db_id}})

Error: Transaction Conflict​

Solution: Another transaction modified the same keys. Options:

  • Retry the transaction
  • Implement optimistic locking
  • Ensure transactions complete quickly

Forgotten Commit​

Problem: Changes not applied because Commit was not called

Solution: Always pair Start Transaction with Commit Transaction:

1. Start Transaction → txn_id
2. Perform operations...
3. Commit Transaction (Transaction Id: {{txn_id}})

Transaction Patterns​

Pattern 1: Try-Catch with Transaction​

Try:
  1. Start Transaction → txn_id
  2. Perform operations...
  3. Commit Transaction
Catch:
  Log error
  (Transaction auto-discarded on error)

Pattern 2: Conditional Commit​

1. Start Transaction → txn_id
2. Get current value → value
3. If condition met:
   Set new value
   Commit Transaction
Else:
   Log "Condition not met"
   (Don't commit, transaction discarded)

Pattern 3: Batch Operations​

1. Start Transaction → txn_id
2. For each item in list:
   Set (Transaction Id: {{txn_id}})
3. Commit Transaction

Transaction Isolation​

Snapshot Isolation​

  • Each transaction sees a consistent snapshot of data
  • Reads within a transaction are consistent
  • Writes are buffered until commit
  • Conflicts detected at commit time

Read-Write Transaction​

  • Can read and write data
  • Changes are isolated until commit
  • All writes succeed or all fail

Performance Considerations​

  • Transaction Overhead - Small overhead per transaction
  • Batch Performance - Batching operations in a transaction is faster than individual writes
  • Lock Contention - Minimize time transactions are held
  • Commit Time - Commits require disk sync
  • Read Performance - Reads within transaction may be slightly slower

Best Practices​

  • Short Transactions - Keep transactions as short as possible
  • One Transaction Per Flow - Typically use one transaction for related operations
  • Error Handling - Always handle transaction errors
  • Explicit Commit - Always explicitly commit transactions
  • Document Logic - Comment why operations are grouped in a transaction
  • Test Rollback - Test that transactions rollback correctly on errors
  • Avoid Nested Transactions - BadgerDB doesn't support nested transactions

When to Use Transactions​

Use Transactions When:​

  • Updating multiple related keys
  • Implementing atomic operations (like transfers)
  • Reading multiple values that must be consistent
  • Performing conditional updates
  • Batch operations that must all succeed

Don't Need Transactions When:​

  • Single key operation (Set/Get/Delete are already atomic)
  • Operations are independent
  • Eventual consistency is acceptable
  • Read-only operations on single keys

Transaction Lifecycle​

Successful Transaction​

Start → Operations → Commit → Changes Applied

Failed Transaction (Error)​

Start → Operations → Error → Auto-Discard → No Changes

Abandoned Transaction (No Commit)​

Start → Operations → Flow Ends → Auto-Discard → No Changes
  • Commit Transaction - Commits and applies transaction changes
  • Get - Reads values within transaction
  • Set - Writes values within transaction
  • Delete - Deletes keys within transaction
  • Start Merge - Alternative for atomic increment/decrement