Connection Pooling Protokoll
Das Connection-Pooling bietet die Möglichkeit, die Aktionen in einer Datei zu protokollieren. Damit können Probleme besser analysiert werden.
Diese Protokollierung sollte nur vorrübergend eingesetzt werden, weil dadurch sehr große Datenmengen produziert werden - vor allem auf Broker mit hoher Last.
Um die Protokollierung für das Connection-Pooling zu aktivieren, muss im ConnectionString die Eigenschaft FSPoolingDebugOutput ergänzt werden.
Dies muss manuell nach dem Publish der Applikation erfolgen, weil diese Eigenschaft nicht im Publish-Dialog konfiguriert werden kann. Diese Angabe kann sowohl für die Runtime-Connection als auch für die Business-Connections gemacht werden.
Beispiel für die Runtime-Connection:
<RuntimeDB ConnectionType="Oracle" ConnectionString="Data Source=ORCLNV270;User ID=FSD35; Password=FSD35;Persist Security Info=False; Pooling=False; FSPoolingMin=5; FSPoolingMax=15; FSPoolingTimeout=60; FSPoolingDebugOutput=C:\temp\FSPool.txt; FSUseAnsiString=False" />
Informationen zur Protokollierung
2012-05-18 20:37:01.449 PID=9976 1;DB=DEV01.sysadm Used 0 Free 0 #025EE953 CREATE Connection 1
2012-05-18 20:37:01.454 PID=9976 1;DB=DEV01.sysadm Used 1 Free 0 #025EE953 GET Connection 1
2012-05-18 20:37:17.991 PID=9976 1;DB=DEV01.sysadm Used 0 Free 1 #025EE953 FREE Connection 1
Eine Protokoll-Zeile beinhaltet die folgenden Felder:
Datum/Uhrzeit
PID - Prozess-ID. Wichtig, wenn auf einem Rechner mehrere Anwendungen laufen, die in dieselbe Datei protokollieren
Pool-Information: eindeutige Nummer des Pools im Prozess; Datenbank
Used: Anzahl der gerade verwendeten Connections
Free: Anzahl der freien Connections im Pool
#xxxxxxxx: Eindeutige ID der Connection. Dabei handelt es sich um den HashCode des Connection-Objektes. Dieser kann dazu verwendet werden, die Aktionen einer Connection sauber zuzuordnen.
Aktion mit Connection-Nummer. Diese Nummer ist innerhalb des Pools eindeutig. Über diese Nummer können die Aktionen einander sauber zugeorndet werden und so z.B. analysiert werden, ob es zu einem "GET Connection" auch ein passendes "FREE Connection" oder "DESTROY Connection" gibt.
CREATE Connection 1: Eine Connection wird erzeugt. Die Information "Free" hängt hinterher, weil die Connection erst nach dieser Aktion in den Pool gepackt wird.
GET Connection 1: Eine Connection wird verwendet. Wenn im Pool keine Connection zur Verfügung steht, dann wird direkt im Vorfeld eine neue Connection geöffnet (CREATE Connection)
FREE Connection 1: Die Connection wird wieder freigegeben und steht dem Pool wieder zur Verfügung. Wenn
DESTROY Connection 1: Die Connection wird beendet. Das passiert,
- wenn bei der Aktion FREE Connection die Anzahl der offenen Connection FSPoolingMax übersteigt, oder
- wenn bei einer Aktion (GET Connection oder FREE Connection) der Timeout einer freien Connection erreicht ist.
DISPOSE POOL: Der Pool wird geleert. Das passiert,
- wenn der Broker beendet wird, oder
wenn die letzte Broker-Sitzung beendet wird.
Wenn bei dieser Aktion noch Connections in Verwendung sind (Used), dann wird für diese Connections der Callstack ausgegeben, mit dem sie verwendet wurden. So kann analysiert werden, wer eine Connection öffnet, sie aber nicht freigibt. Diese Connections werden nicht vom Pool geschlossen. Mit dieser Aktion wird der komplette Pool zurückgesetzt. Die Informationen "Used" und "Free" beginnen wieder bei 0. Das ist auch der Fall, wenn zuvor noch Connections geöffnet waren.
ESCALATION OF USED CONNECTIONS: Wenn die Anzahl der benutzten Connctions im Pool 30 übersteigt, dann werden einmalig pro Pool die momentan benutzten Connections mit den Callstacks, durch die sie geöffnet wurden, ausgegeben.
Die einzelnen Felder sind mit Tabulator getrennt. So können Sie diese Daten sehr gut z.B. in Excel kopieren und weiter analysieren.
Auf einem Rechner können mehrere Prozesse in dasselbe Protokoll schreiben, die Routine ist entsprechend abgesichert. Die Absicherung funktioniert NICHT auf Netzlaufwerken für mehrere Rechner!