AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Wissen, wer in Firebird einen lock conflict ausgelöst hat

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

Ein Thema von MyRealName · begonnen am 15. Okt 2016 · letzter Beitrag vom 18. Okt 2016
Antwort Antwort
Benutzerbild von MyRealName
MyRealName

Registriert seit: 19. Okt 2003
Ort: Heilbronn
430 Beiträge
 
Delphi 10.3 Rio
 
#1

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

  Alt 15. Okt 2016, 15:54
Datenbank: Firbird • Version: 3 • Zugriff über: UniDAC
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
  Mit Zitat antworten Zitat
Benutzerbild von IBExpert
IBExpert

Registriert seit: 15. Mär 2005
448 Beiträge
 
FreePascal / Lazarus
 
#2

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

  Alt 15. Okt 2016, 16:09
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.
Holger Klemt
www.ibexpert.com - IBExpert GmbH
Oldenburger Str 233 - 26203 Wardenburg - Germany
IBExpert and Firebird Power Workshops jederzeit auch als Firmenschulung
  Mit Zitat antworten Zitat
Benutzerbild von MyRealName
MyRealName

Registriert seit: 19. Okt 2003
Ort: Heilbronn
430 Beiträge
 
Delphi 10.3 Rio
 
#3

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

  Alt 15. Okt 2016, 16:18
Genau das, was ich brauchte, danke...
  Mit Zitat antworten Zitat
tsteinmaurer

Registriert seit: 8. Sep 2008
Ort: Linz, Österreich
527 Beiträge
 
#4

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

  Alt 18. Okt 2016, 10:04
@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
  Mit Zitat antworten Zitat
Benutzerbild von MyRealName
MyRealName

Registriert seit: 19. Okt 2003
Ort: Heilbronn
430 Beiträge
 
Delphi 10.3 Rio
 
#5

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

  Alt 18. Okt 2016, 14:20
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
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 12:13 Uhr.
Powered by vBulletin® Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2020 by Daniel R. Wolf