Fix FireDAC Connection Pool Exhaustion | RAD Studio

Diagnose and resolve EFDConnPoolException in RAD Studio. This guide covers identifying connection leaks, tuning MaxPoolSize, and using FireDAC tracing to stop pool exhaustion.

Recognizable Symptoms

Under concurrent load, a RAD Studio application may throw an EFDConnPoolException with messages such as "Cannot allocate connection" or "Pool exhausted". Users typically experience hanging requests, UI freezes, or database timeouts. These symptoms usually manifest during peak activity or after the application has been running for an extended period.

Root Cause Analysis

Potential Cause	Diagnostic Indicator
Insufficient `MaxPoolSize`	Errors occur exactly when concurrent user count hits a specific threshold.
Connection Leaks	Pool usage grows steadily over time and never returns to zero, even when idle.
Transaction Hanging	Connections remain "active" in the pool despite no active queries being executed.
Pooling Disabled	`Params['Pooling']` is set to False, causing high overhead and server-side connection limits.

Diagnostic Workflow

Enable FireDAC Tracing: Use TFDEventAlerter to monitor acquire and release events. Run this in a dedicated initialization routine.

// Run in application initialization (requires FireDAC.Stan.EventBroker) 
procedure SetupFDTracing;
begin
  // Create monitor to log connection lifecycle
  FDMonitor := TFDEventAlerter.Create(nil);
  FDMonitor.Active := True;
  FDMonitor.TraceFileName := 'C:\logs\FDTrace.log';
end;

Verify Pool Configuration: Check the connection parameters to ensure pooling is active and the limit is appropriate for your hardware.

// Check if pooling is enabled
if FDConnection1.Params.Values['Pooling'] = 'False' then
  Log('Warning: Pooling is disabled');

// Check current max limit
Log('Max Pool Size: ' + FDConnection1.Params.Values['MaxPoolSize']);

Audit Connection Lifecycle: Search the codebase for TFDConnection.Open calls. Ensure every open call is paired with a Close call inside a finally block.

Monitor Real-time Usage: Implement a diagnostic heartbeat or log to track current pool saturation.

// Run this during a load test to check saturation
Log(Format('Current Pool Usage: %d / %d', [FDConnection1.Pool.Count, FDConnection1.Pool.Max]));

Fixes Tied to Findings

For Low MaxPoolSize: Increase the MaxPoolSize parameter.
```
FDConnection1.Params.Values['MaxPoolSize'] := '100';
```
Caution: Do not exceed database server limits (e.g., avoid >200 without server tuning) to prevent overwhelming the backend.
For Connection Leaks: Implement strict try..finally blocks. This ensures the connection returns to the pool even if a runtime exception occurs.
```
try
  FDConnection1.Open;
  // Execute database logic
finally
  FDConnection1.Close;
end;
```
For Hanging Transactions: Ensure all transactions are explicitly committed or rolled back. A connection cannot return to the pool while a transaction is active.
```
FDTransaction1.StartTransaction;
try
  // Perform updates
  FDTransaction1.Commit;
except
  FDTransaction1.Rollback;
  raise;
end;
```
For Stale Connections: Set ConnectionLifeTime to recycle connections that may have been silently dropped by the server.
```
FDConnection1.Params.Values['ConnectionLifeTime'] := '300'; // Recycles every 5 minutes
```

Verification and Testing

To verify the fix, perform the following checks:

Load Testing: Use a tool like Apache JMeter or the RAD Studio performance profiler to simulate peak concurrent users. Confirm EFDConnPoolException no longer triggers.
Trace Log Audit: Review the FDTrace.log. The total number of "Acquire" events must match the total number of "Release" events.
Resource Monitoring: Observe system memory and CPU. Stable resource usage over a 24-hour period indicates that connections are being recycled correctly.

Escalation Criteria

If pool exhaustion persists after applying these fixes, gather the following data for Embarcadero support:

The complete FireDAC trace log from a failure event.
The application load profile (number of concurrent users and average transaction duration).
The exact RAD Studio version and the database driver version being used.
Database server logs showing the number of active sessions during the crash.

Limitations and Risks

Server Overhead: Increasing MaxPoolSize too aggressively can lead to "Too many connections" errors on the database server side.
Tracing Performance: FireDAC tracing generates significant I/O. Disable tracing in production environments after diagnostics are complete.
State Management: Disabling pooling for debugging can hide race conditions that only appear when connections are reused.

Resolving FireDAC Connection Pool Exhaustion in RAD Studio