Cache DB Connections

[hotti]

Tach!

Datenbank-Verbindungen werden im eigenen Haptspeicher gecached.
Beim ersten Aufruf der Methode wird die Verbindung hergestellt und verbleibt danach im Hauptspeicher, das ist der Hash %CC_DAL.
Bei jedem weiteren Aufruf mit denselben Parametern (DB-Name, Tab-Name) wird keine neue Verbindung hergestellt, sondern die Instanz aus dem RAM geladen.

Und nun muss man nur noch sicherstellen, dass der nachfolgende Client an keine DB-Session-Daten des vorherigen Client rankommt, und sich dann die Frage stellen, ob Sicherheit und der Aufwand dafür nicht vielleicht die Kosten eines neuen Verbindungsaufbaus übersteigen.

Ja. Shared-Connections bringen "Einiges ist zu beachten" so mit sich. Mein Beispiel ist im Prinzip eine Singleton-Factory: Alle zurückgegebenen Instanzen sind Singletons, die Methode verhält sich statisch, d.h., die Instanzen werden nur einmal erstellt.

Es ist möglich, mit dem bischen Perl-Code das statische Verhalten weiter einzuschränken, z.B. so, dass eine DB-Connection-Instanz an einen bestimmten URL gebunden ist (Parameter wären dann DB_NAME, DB_TABLE, OWNER_URL).

Der Verbindungsaufbau zu für das Web vorgesehenen Datenbanksystemen ist heutzutage meist ausreichend schnell, so dass sich ein Connection-Pool nur in solchen Fällen lohnt, wie zum Beispiel einem langsamen Netzwerk.

In Perl ist das auch so. Die meiste Zeit geht drauf, wenn der DBI-Layer (use DBI;) kompiliert wird. Danach ist eine Verbindung sehr schnell hergestellt (liegt im MilliSec-Bereich, wenn WebserverHost == DBserverHost).

Weiterhin schönen Sonntag ;)