Viele Anwendungen verwalten einen eigenen Connection Pool im Mittel-Tier. Das funktioniert gut, kann aber bei sehr vielen Prozessen oder kurzlebigen Verbindungen viele Datenbanksessions binden. Oracle AI Database 26ai erweitert Database Resident Connection Pooling (DRCP) um Implicit Connection Pooling: Die Datenbank kann eine Session automatisch an eine Anwendung hängen und sie an einer definierten Grenze wieder in den Pool zurückgeben.
1. Was automatisch passiert
Beim DRCP werden Serverprozesse und Sessions in einem Datenbankpool bereitgestellt. Mit Implicit Connection Pooling wird eine verfügbare Session zur Laufzeit einer Anwendung zugeordnet und nach einer definierten Grenze wieder freigegeben – auch wenn die Anwendung keine explizite Pooling-API aufruft.
Das ist interessant für Anwendungen, die direkte Datenbankverbindungen aufbauen, aber keine OCI-Session-Pools oder JDBC UCP einsetzen. Auch Middle-Tier-Server mit vielen Verbindungen können Sessions besser multiplexen, wenn eine Verbindung nicht dauerhaft einen Datenbankprozess blockieren muss.
2. POOL_BOUNDARY im Connect String
Die Konfiguration erfolgt clientseitig über POOL_BOUNDARY in CONNECT_DATA. Für DRCP muss außerdem SERVER=POOLED gesetzt werden:
app_pool_stmt =
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=db.example)(PORT=1521))
(CONNECT_DATA=
(SERVICE_NAME=app_pdb)
(SERVER=POOLED)
(POOL_BOUNDARY=STATEMENT)))Alternativ kann POOL_BOUNDARY=TRANSACTION verwendet werden. Die Statement-Grenze gibt eine stateless Session bereits nach einem vollständig abgearbeiteten Statement zurück. Die Transaction-Grenze orientiert sich am Ende der Transaktion oder an einem Zustand, in dem keine aktive Transaktion mehr vorhanden ist.
3. Session State entscheidet
Eine Session gilt nur dann als implizit stateless, wenn alle offenen Cursor vollständig gelesen wurden, keine aktive Transaktion läuft und keine temporären LOBs oder gefüllten temporären Tabellen offen sind. Andernfalls bleibt sie stateful und wird nicht an jeder Statement-Grenze freigegeben.
Das ist ein wichtiger Architekturpunkt: Wer Session State über mehrere Requests hinweg erwartet, darf nicht einfach die Statement-Grenze wählen. Wer dagegen nur kurze, unabhängige Statements ausführt, kann damit Ressourcen schneller zurückgeben. Anwendungscode muss Cursor, Commit/Rollback und temporäre Objekte vollständig behandeln.
4. Fehlerbilder und Betriebsgrenzen
Nach einer impliziten Freigabe können offene Cursor ungültig sein. Auch temporäre LOBs oder andere zustandsabhängige Objekte dürfen nicht so behandelt werden, als bliebe dieselbe Session garantiert erhalten. Bei einer Transaktionsgrenze müssen Commit und Rollback daher genau zur fachlichen Einheit passen.
Die Statement-Cache-Situation sollte ebenfalls geprüft werden: Bei impliziter Freigabe wird der Statement Cache geleert. Session Cached Cursors können helfen, wiederholte Ausführungen effizienter zu halten. Das muss aber mit realen Workloads gemessen werden, statt pauschal einen Parameter zu setzen.
5. Sicherer Rollout
- DRCP für eine klar abgegrenzte PDB oder einen Service konfigurieren.
- Verbindung mit
SERVER=POOLEDund passenderPOOL_BOUNDARYin einer Testumgebung einrichten. - Stateless- und Stateful-Szenarien mit Cursor, Transaktion, LOB und temporären Tabellen testen.
- Sessions, Pool-Auslastung, Wartezeiten und Fehlerraten über
GV$CPOOL_STATSund verwandte Views beobachten. - Session State zwischen Requests explizit initialisieren oder zurücksetzen.
- Statement Cache, Transaktionsgrenzen und Retry-Verhalten vor dem Rollout messen.
Fazit
Implicit Connection Pooling in Oracle AI Database 26ai kann DRCP für Anwendungen nutzbar machen, die bisher keine Pooling-API einsetzen. Der Gewinn entsteht durch besseres Session-Multiplexing, nicht durch das bloße Setzen eines Parameters. Mit sauberem Session-State-Design, passenden Pool-Grenzen und messbarem Monitoring wird daraus eine belastbare Skalierungsoption.
Weiterführend: Oracles Dokumentation zu Implicit Connection Pooling, die Neuerungen zur Application Connectivity und die Connect-String-Parameter.