Transaction Manager Core Laravel Package

Getting Started

Minimal Setup

1. Installation

   composer require aeatech/transaction-manager-core
   

   No service provider or facade needed—use the Aeatech\TransactionManager\TransactionManager class directly.

2. Basic Usage

   use Aeatech\TransactionManager\TransactionManager;
   
   $manager = new TransactionManager();
   $manager->run(function () {
       // Your transactional logic here
       DB::table('users')->insert(['name' => 'John']);
       DB::table('orders')->insert(['user_id' => 1, 'amount' => 100]);
   });
   

3. First Use Case Wrap a high-load operation (e.g., bulk inserts, cross-table updates) in a transaction to ensure atomicity without blocking the entire request.

Implementation Patterns

Workflow Integration

1. Middleware for API Endpoints

   public function handle(Request $request, Closure $next) {
       $manager = new TransactionManager();
       $manager->run(function () use ($request) {
           // Process request logic
           return $next($request);
       });
   }
   

2. Queue Job Wrapping

   public function handle() {
       $manager = new TransactionManager();
       $manager->run(function () {
           // Queue job logic (e.g., batch processing)
       });
   }
   

3. Database-Agnostic Transactions

   • Works with Eloquent, Query Builder, or raw PDO.
   • Supports nested transactions (if your DB driver allows it).

Performance Optimization

• Bulk Operations: Ideal for high-load scenarios (e.g., importing 10K+ records).

  $manager->run(function () {
      DB::table('logs')->insert($batchData);
  });
  

• Retry Logic: Combine with try-catch for deadlocks.

  $manager->run(function () {
      DB::transaction(function () {
          // Risky operations
      });
  }, 3); // Retry 3 times on failure
  

Gotchas and Tips

Pitfalls

1. Nested Transactions

   • Some databases (e.g., MySQL) don’t support nested transactions natively. Use savepoints if needed.
   • The package defaults to flat transactions—explicitly configure for nested behavior if required.

2. Connection Handling

   • Ensure the same connection is used across all DB operations in the transaction. Mixing connections (e.g., mysql + pgsql) will fail.

3. Timeouts

   • Long-running transactions may hit DB timeouts. Monitor with:

     $manager->run(function () { /* ... */ }, null, 30); // 30-second timeout
     

Debugging

• Rollback Analysis: Use DB::enableQueryLog() to inspect failed queries.
• Logging: Wrap in a try-catch to log transaction failures:

  try {
      $manager->run(function () { /* ... */ });
  } catch (\Exception $e) {
      Log::error('Transaction failed: ' . $e->getMessage());
  }
  

Extension Points

1. Custom Rollback Logic Override the default rollback behavior by extending the TransactionManager class:

   class CustomManager extends TransactionManager {
       protected function onRollback() {
           // Custom cleanup (e.g., log, notify)
       }
   }
   

2. Event Hooks Listen for transaction.start/transaction.commit/transaction.rollback events (if the package supports them; check docs).

3. Configuration

   • Adjust retry delays, timeout thresholds, or isolation levels via constructor options:

     $manager = new TransactionManager([
         'retry_delay' => 100, // ms
         'isolation_level' => 'serializable',
     ]);