Deadlocks, was tun ? (FB 1.5)

[Sascha-L]

Guten Tag,
ich habe ein paar fragen zum Thema Deadlocks...
Ich habe 2 Stored Procedures in einem Projekt, diese greifen jeweils auf 2 (die gleichen) Tabellen zu.
Die Prozeduren machen um Prinziep nichts anderes als ein Select und 2 Updates, werden allerdings in regelmäßigen abständen aufgerufen, ergo häufig benutzt. Das kann auch eine ganze Weile lang gut gehn, blos irgendwann bekomme ich eine Fehlermedlung "Deadlock". Das wirfst meine ganze Clientkette durcheinander und sorgt für unordnung in jeglichen clients sowie in der Datenbank, außerdem geht eine Weile erstmal nichts mehr (Die 10 sec. Deadlocktime).
Meine eigentliche Frage ist, gibt es eine möglichkeit diesen Deadlock zu verhindern ?

Aufbau der Stored Procedures

Prozedur 1

Select Tabelle A

Update Tabelle A

Update Tabelle B


Prozedur 2

Select Tabelle B

Update tabelle B

Update Tabelle A

Ich habe auch schon veruscht in den Prozeduren die Befehlsfolge zu tauschen, jedoch ohne Erfolg.

Vielen Dank im Vorraus


MfG Sascha Lütkemeier

[mkinzler]

Etwas Code wäre u.U. hilfreich

[Sascha-L]

OK, hier ist erstmal der Code einer Stored Procedure und der Aufruf aus Delphi, hoffe das bringt euch was, aber ich bin auch für Ideen offen, mit denen ich generell Deadlocks vermeiden kann .

SQL-Code:

begin
Select count(*) from t_swpoolstr into kcount;

update t_auftraege set
    Kundenname = 'Test1',
    Auftragsnr = kcount,
    Liefertermin = '28.03.2008 17:22:30',
    Datumuhrzeit = '27.03.2008 18:30:22',
    Status = 1
where ID = 380;

update t_swpoolstr set
    PositionenID = kcount,
    Poolstr = 'TestString 1',
    Status = 1
where ID = 118.417;
  suspend;
end

Die 2. SP sieht ziemlich genauso aus, nur dass die angesprochene Tabelle immer genau die andere ist und hier der Versprochene Aufruf:

Delphi-Quellcode:

procedure TForm1.btn_execspClick(Sender: TObject);
begin
  If DataBase1.InTransaction = False Then DataBase1.StartTransaction;
  Try
  Begin
    DataSource1.DataSet:= StoredProc1;
    StoredProc1.StoredProcName:= ed_storedp.Text;
    StoredProc1.ExecProc;
    Database1.Commit;
  end;
  Except
    Database1.Rollback;
    ShowMessage('Ausführung nicht möglich, Fehler !');
    Timer2.Enabled:= false;
  End;
end;

[mkinzler]

Ich würde die Spalte PositionenID streichen. da hier nur eine Redundanz erzeugt wird.
Zudem verstehe ich nicht ganz was hier gemacht wird. Du erzeugst aus der Anzahl von Datensätzen einer Tabelle eine Auftragsnummer?

[Sascha-L]

Das ist eine Analogi, ich musste mir schnell etwas machen um dne Ernstfall zu simulieren, was da genau passiert ist unwichtig, nur, dass in einer solchen konstellation auf die Datenbanken zugegriffen wird, und hierbei ein Deadlock entsteht, der muss aber irgendwie weck, da er Probleme macht...

[mkinzler]

-Datensatz explizit locken
-Select for update
-Logik überprüfen

[Sascha-L]

Ich bin ziemlicher neuling, verstehe also nicht ganz, was du damit meinst bzw. wie ich einen Datensatz zum Beispiel expliziet locke...

[mkinzler]

Wenn du einen Datensatz lockst, dann kann er von keinem anderen mehr geöffnet werden.

[Sascha-L]

Dass ist mir schon klar, die frage war eher wie ich so etwas mache, und was du mit den anderen Punkten meinst ^^

MfG

Sascha

[mkinzler]

-Bei einem select for update wird der Datensatz automatisch gesperrt.
-U.U. kann man die Logik der Abfrage oder die Datenbankstruktur so anpassen, dass die Gefahr von Deadlocks minimiert wird.
Aber ohne die Abfragen, DB-Struktur zu kennen, kann man da nichts Näheres sagen.

http://www.ibphoenix.com/main.nfs?a=...ge=ibp_locking
http://www.interbase-world.com/en/articles/805.php
http://entwickler-magazin.de/zonen/p...783,neu,1.html
http://ibdeveloper.com/issues/issue-...he-lock-table/