Deadlockopfer bei TDataset.Refresh

[jobo]

Lock Escalation ist ziemlich ätzend bei MSSQL. Aber man muss sagen, das geschieht nicht aus Spaß oder gar Boshaftigkeit, sondern in "Notlagen".
Wenn Lock Escalation eintritt, würde man dem Server wohl anmerken, dass er "Atemnot" hat (außer er ist gut aus dem Blick weg virtualisiert)

Ein Refresh würde m.E. auch kein Lock verursachen oder auslösen, eher würde ein Wait stattfinden, bis commitete Daten vorliegen. (aber ich hab damit schon ewig nichts mehr gemacht, also unsicher)

Frage wäre, ob das Refresh ein (interner) Teil eines Post ist. Es gibt ja diese Mechnismen, die nachschauen, ob noch alles seine Ordnung hat.
Also vor dem wirklichen Post vergleichen, ob die Daten, die vor dem Edit geholt wurden, auch noch so vorhanden sind. (Damit nicht die Änderungen eines anderen überschrieben werden, ohne dass es bemerkt wird.)
Die SQL Variante davon ist in D oder anderen Umgebungen sowas wie:
Update <meineTabelle> set <irgendwelcheFelder> = <irgendwelcheWert> where id=<schlüsselwert> and <alleFelder>=<alleVorigenWerte>

[Bernhard Geyer]

Beim MS SQL Server muss man auf DB-Ebene die richtige Einstellung machen, damit er nicht bescheuerte Locks beim Lesen setzt.
Geht seit der 7er Version, ist aber Standardmäßig deaktiviert.

[haentschman]

Danke für die vielen Infos...

Zitat:

Der MSSQL Server lockt beim Lesen

Zitat:

Beim MS SQL Server muss man auf DB-Ebene die richtige Einstellung machen, damit er nicht bescheuerte Locks beim Lesen setzt.

Kannst du mir die Einstellung sagen? Was, wo?

Zitat:

Sicher, dass es nicht das "Post" davor ist, dass den Deadlock auslöst?

Ich habe ein eigenes "System" was die doppelte Speicherung "verhindert" (eigene Lock Tabelle). Leider ist das auf die betroffene Tabelle noch nicht ausgeweitet. Deshalb kann ich es nicht ausschließen. Aber das Refresh wird im "AfterPost" ausgelöst...das sollte das Post fertig sein.

[TigerLilly]

Zitat von haentschman:

Danke für die vielen Infos...

Zitat:

Der MSSQL Server lockt beim Lesen

Das Locken beim Lesen ist schon sinnvoll. Wer das nicht will, kann mit WITH (NOLOCK) lesen + daran denken, was uU passieren kann. Das Problem bei der Eskalation ist, dass Sätze gesperrt werden, die mit der ursprünglichen Anforderung nichts zu tun haben und nur zufällig auf der gleichen Page (oder in derselben Tabelle) liegen.

[haentschman]

Zitat:

Wer das nicht will, kann mit WITH (NOLOCK) lesen

...ich werde mir jetzt bei den "ReadOnly" Datenmengen das WITH NOLOCK mal ausprobieren.

Code:

SET LOCK_TIMEOUT

...ist das eine Möglichkeit?
Nachtrag: mal auf 1000 gesetzt. Warten wir auf den nächsten Fehler...

[mjustin]

So ein Zufall: heute ist mir dieser "Deadlockopfer"-Fall (ebenfalls MS SQL) begegnet.

Code:

Die Transaktion (Prozess-ID 790) befand sich auf Sperre Ressourcen aufgrund eines anderen Prozesses in einer Deadlocksituation und wurde als Deadlockopfer ausgewählt. Führen Sie die Transaktion erneut aus.

bzw.

Code:

Die Transaktion (Prozess-ID 871) befand sich auf Sperre | Kommunikationspuffer Ressourcen aufgrund eines anderen Prozesses in einer Deadlocksituation und wurde als Deadlockopfer ausgewählt. Führen Sie die Transaktion erneut aus.; nested exception is java.sql.SQLException: Die Transaktion (Prozess-ID 871) befand sich auf Sperre | Kommunikationspuffer Ressourcen aufgrund eines anderen Prozesses in einer Deadlocksituation und wurde als Deadlockopfer ausgewählt. Führen Sie die Transaktion erneut aus.

Danke an die Beitragenden, eventuell kann ich später auch etwas beisteuern.

[haentschman]

Moin...

Update:

Delphi-Quellcode:

procedure TDMED.FDQAdrAfterPost(DataSet: TDataSet);
var
  Data: TDataSet;
begin
  Data := dmRepositories.EdRepoExtLookupAdr.Properties.DataController.DataSet;
  if Data.CanRefresh then
  begin
    Data.Refresh;
  end;
end;

...hat nicht funktioniert.

Delphi-Quellcode:

procedure TDMED.FDQAdrAfterPost(DataSet: TDataSet);
begin
  repeat
    Sleep(100);
  until not TFDQuery(DataSet).Connection.InTransaction;

  dmRepositories.EdRepoExtLookupAdr.Properties.DataController.DataSet.Refresh;
end;

...das hat bis dato keinen Deadlock mehr ausgelöst.

Da ich das an mehreren Stellen habe mache ich mir eine function in meinen Tools...

[himitsu]

Dann solltest du aber kein BeginTransaction in deinem Code haben, weil dann dieser Code hängen bleibt, weil diese Tansaction nicht nach dem Post automatisch beendet wird.

[haentschman]

Moin...

genervte Grüße... Kaum redet man drüber geht es nicht mehr.

Zitat:

exception class : EMSSQLNativeException
exception message : [FireDAC][Phys][ODBC][Microsoft][SQL Server Native Client 11.0][SQL Server]Die Transaktion (Prozess-ID 9515) befand sich auf Sperre Ressourcen aufgrund eines anderen Prozesses in einer Deadlocksituation und wurde als Deadlockopfer ausgewählt. Führen Sie die Transaktion erneut aus.

Wie kriege ich raus wer der Übeltäter ist?

Zitat:

aufgrund eines anderen Prozesses

@himitsu:
Logisch... Ich habe noch eine Abbruchbedingung mit drin...(Anzahl Versuche)