Wissen, wer in Firebird einen lock conflict ausgelöst hat

[MyRealName]

Hallo,

vielleicht wissen unsere FB Spezialisten Rat :

Manchmal passiert bei mir an einer Stelle ein lock conflict, der nicht auftreten sollte. Der Kunde schwört, er hat nichts gemacht..
Gibt es eine Möglichkleit, zumindest mit den MON$XXXX Tabellen rauszufinden, welcher Rechner es war ? ich weiss, dass bei den Attachments Rechnername/IP und OS_Username gelogged sind...

Danke schonma

Helge

[IBExpert]

wenn du im Exception text von firebird die Transaktionsnummer findest, die für den Konflikt veranwtortlich ist, kannst du ggf zeitnah über mon$transaction die mon$attachement_id dazu raussuchen und dazu dann in mon$attachments die IP Adresse und prozess ID finden, es sei denn, das sind dehr schnell laufende Transaktionen, die schon abgeschlossen sind, weil in mon$ Tabellen nur die daten der gerade aktiven Connections enthalten sind.

[MyRealName]

Genau das, was ich brauchte, danke...

[tsteinmaurer]

@MyRealName: Da es durchaus vorkommen kann, dass die gesuchte Info in den MON$ Tabellen nicht mehr enthalten ist, kann ich jedem nur empfehlen, dass man während der Entwicklung ständig ein Trace mit der Firebird Trace API mitlaufen lässt.

Davon kann man a) extrem viel lernen, was z.b. die Zugriffskomponenten bzw. man selbst so verbricht bzw. b) auch solche Fehlermeldungen zeitlich besser korrelieren.

Eine kompakte Einführung zur Firebird Trace API gibt es z.b. in meinem Entwickler Magazin Artikel hier (schon älter, aber die Grundprinzipien haben sich nicht geändert): http://www.iblogmanager.com/download...rebird_2.5.pdf

Idealerweise macht man das ganze dann noch mit einem gescheiten Tool: FB TraceManager, IBExpert etc.

Lg,
Thomas

[MyRealName]

Ich habe das mit dem monitor mal eingebaut. Das Problem ist, dass ich an dieser Stelle, wo ich bin im Code, nur DbExpress nutzen kann anstatt UniDAC oder IbDAC. IbDAC hätte ich ein TIBCTraceAudit Komponente.
Es gibt aber ein Problem, wo ich UniDAC nicht im Mainthread und in extra threads nutzen kann, das schmiert dann beim Verlassen der Anwendung ab. Und ja, im Thread habe ich eigene Verbindung, Transaction, Queries etc. Und zwischen MainThread und DB Thread gibt es nur einen Kommunikationskanal über Messages. Die von DevArt wollen allerdings ein Demo haben dazu und das kann ich aus Zeitgründen im Moment nicht bauen.

Gute Nachricht ist : Der Fehler tritt in einer Queue auf, wo ich alle Dokumente zum Verarbeiten reinwerfe, die lässt immer nur ein Dokument durch (stammt aus einer Zeit, wo UniDAC noch keine WAIT_TRANSACTION konnte). Und der Deadlock kommt nur gaaanz selten mal in 2 Kundeninstallationen (von denen ich weiss) vor. Ich will da einfach mal sehen, ob da jemand noch mit einem anderen Programm (wie IbExpert) rumfummelt, oder einen Prozess in meiner Anwendung laufen hat, der nicht laufen sollte. Da ich beim Deadlock sofort nachsehe, sollte die Chance gross sein, dass diese Transaction noch lebt.

Helge