Deadlock

[olaf]

Hallo,
ich bekomme bei einem gleichzeitigen Zugriff im Netzwerk immer einen Deadlock. Warum werden die Transactionen nicht hintereinander abgearbeitet ober wie kann ich den Ablauf der Transactionen steuern. Ich habe auch schon, wie in der Hilfe von IBDAC beschrieben, vor dem Starten der Transaction den Zustand abgefragt und dann ein commit oder rollback ausgeführt; wie:

Delphi-Quellcode:

If tra=active then
Tra.commit;

Isolationlevel snapshot brachte auch keinen Erfolg.

Muß ich einen anderen Isolatinlevel wählen. Wie behandelt Ihr gleichzeitige Zugriffe. Irgendetwas muß ich grundsätzlich falsch machen. Es liegt bestimmt nicht an Firebird.



Wäre für eure Hilfe sehr dankbar.
Olaf

Die stored procedure rufe ich so auf:

Delphi-Quellcode:

procedure TNetzwerk.setvorname;
var
 spex: TIBCStoredProc;
 tra: TIBCTransaction;
begin
 try
 tra:=TIBCTransaction.Create(dm);
 tra.DefaultConnection:=dm.ConMtermin;
 tra.DefaultCloseAction:=taRollback;
 tra.IsolationLevel:=iblReadCommitted;

 spex:=TIBCStoredProc.Create(dm);
 spex.Transaction:=tra;
 spex.Connection:=dm.ConMtermin;
 tra.StartTransaction;
  spex.StoredProcName:='INS_UPD_VORNAMEBUCHEN';
  spex.Prepare;
  spex.ParamByName('NA').value:=trim(buchenFR.AdvEdit2.Text);
  spex.ParamByName('GES').value:=buchenFR.dialoggeschlecht;
  spex.Execute;
 tra.Commit;
 finally
 spex.UnPrepare;
 spex.Free;
 tra.free;
 end;
end;

Die SP:

DECLARE ANZ INTEGER;
BEGIN
BEGIN

SELECT COUNT(NAME) as ANZAHL
FROM VORNAME
WHERE NAME = :NA
INTO :ANZ;

IF (ANZ=0) THEN
BEGIN
INSERT INTO VORNAME(NAME, GESCHLECHT)
VALUES( :NA, :GES);
END
ELSE
BEGIN
UPDATE VORNAME SET
GESCHLECHT = :GES
WHERE VORNAME.NAME = :NA;
END

END
END

[MGC]

Hallo,

drei kurze Fragen:

1. Ist das IBDAC nicht nur für Interbase? Du verwendest ja Firebird.
2. Wird ggf. die Transaction über spex automatisch beim Aufruf der stored Procedure gestartet und Du bekommst einen Fehler weil Du es zwischendrin nochmals manuel startest?
3. Oder solltest Du die Transaction starten nachdem Du die stored Procedure aufgerufen hast, bzw. ruft Deine Transaction die Procedure selbst auf?

Ich werde aus Deinem Code nicht ganz schlau.

EDIT: Habs gerade nochmal nachgelesen, das IBDAC ist auch für Firebird...

[tsteinmaurer]

Deadlocks (obwohl es eigentlich keine wirklichen Deadlocks sind) treten in der Regel auf, wenn zwei konkurrierende Transaktionen den selben Datensatz schreibend ändern möchten. Kann das bei dir der Fall sein?

Isolation-Level kommt drauf an, welche Konsistenzanforderungen du bzgl. Ergebnismenge hast. Grundsätzlich gilt die Regel, dass sich lesende und schreibende Operationen auf den selben Datensatz nicht sperren, außer man verwendet bei ReadCommitted NO_REC_VERSION für die Transaktion. Weiss nicht was da IBDAC standardmäßig nimmt, aber ich vermute mal REC_VERSION bei ReadCommitted, was ok wäre.

Ich würde auch sagen, dass dein Exception-Handling nicht sauber. Bei dir sollte es etwas in Richtung wie folgt sein:

Delphi-Quellcode:

tra:=TIBCTransaction.Create(dm);
spex:=TIBCStoredProc.Create(dm);
try
  try
    -- Do stuff
    tra.Commit;
  except
    tra.Rollback;
    raise; // Optional
  end;
finally
  spex.Free;
  tra.Free;
end;

Auch deine SP bzgl. dem SELECT COUNT(*) könnte bremsen, abhängig davon, wieviele Datensätze in der Ergebnismenge sind. Für einen "Existenz-Check" kann/sollte man immer IF(EXISTS(...)) THEN verwenden.

[olaf]

Hallo,

habe ich auch schon vermutet MGC.
das automatische commit habe ich jetzt ausgeschaltet, sowohl für die Verbindung als auch für den Aufruf der SP, hat aber nichts genützt.


Guter Tip (If(exist..) und bei IBDAC ist REC_Version eingestellt.

olaf

[tsteinmaurer]

Wennst du eine Transaktion explizit startest, dann sollte ein aktivierter AutoCommit Modus für die Zeitdauer bis zum Commit/Rollback eh deaktiviert sein. Da du 2.5 einsetzt, kannst du ganz einfach ein MERGE bzw. UPDATE OR INSERT verwenden, aber das wird vermutlich nicht dein Problem lösen, aber prinzipiell ist hier eine SP nicht notwendig, wenn es darum geht, ein INSERT oder UPDATE zu machen.

Welche Exception bekommst du denn genau?

Btw, wir könnten uns das auch gezielter via z.B. TeamViewer ansehen, aber das Ganze wäre dann nicht mehr kostenlos. Bei Interesse/Bedarf einfach via Skype kontaktieren (thomas.steinmaurer)

Wir können auch gerne hier eine Diskussion weiterführen. Dauert halt länger ...

[Neutral General]

Zum Thema SPs:

Es gibt auch sogenannte EXECUTE BLOCKs. Das sind quasi "SPs für zwischendurch".
Sollte man sich auf jeden Fall mal anschauen. Einige Sachen kann man damit sehr
schön und vor allem schnell lösen ohne extra eine SP schreiben zu müssen:

http://www.firebirdsql.org/refdocs/l...execblock.html

[olaf]

Hallo,

die Exception lautet:
Log conflict on no wait transaction deadlog update conflicts with concurrent update concurrent transaction nr 33691

olaf

[tsteinmaurer]

Olaf,

dann geh mit dieser TransactionID in die Monitoring-Tabellen, dann wirst du hoffentlich sehen, welche konkurrierenden Updates sich blockieren.

[Iwo Asnet]

Diese 'no wait' transaction ist doch kein Problem. Jedenfalls ist das kein Deadlock.
Das soll sogar so sein. Normalerweise wartet eine Transaktion, bis sie an der Reihe ist (außer eben: Deadlock). Eine 'no wait' Transaktion bricht sofort ab. Dafür sind sie im normalfall wesentlich schneller.

Abhilfe: Nochmal versuchen oder die 'no wait'Option ausschalten

[olaf]

Hallo,

ich habe die no_wait option rausgenommen. Jetzt bekomme ich keine Fehlermeldung mehr.

olaf