Ok, das mit dem
Mutex habe ich jetzt auch verstanden, damit garantierst du, dass nur einer global auf die Datenbank zugreift. Ansonsten schmeisst der
Mutex eine
Exception. Das ändert aber nichts an meinem Vorschlag, ausser, dass man den Closure noch erweitert um ein Predicate, dass den
Exception-Typ bekommt und dort entschieden wird, ob da wirklich weitergemacht werden soll, denn eine
EAccessViolation
ist nichts, wo ich es nochmals versuchen müsste, da ich ja eigentlich auf nur auf den
Mutex warte.
Die
Exception hat nichts mit dem
Mutex zu tun, sondern mit der Absicherung der
TCP-
IP-Verbindung oder sonstigen Problemen:
Der
Mutex dient der gemeinsamen Nutzung der Verbindung zum Server.
Zitat von
Sir Rufo:
Im Übrigen sollten die Aufrufe FDB.TuDies und FDB.TuDas sich selber um den Lock (wieso eigentlich
Mutex, brauchst du das Session- bzw. System-Global? Sonst würde ein TMonitor reichen) kümmern, denn der scheint ja immanent wichtig zu sein, also gehört der in diese Methoden rein.
Warum sollten die Aufrufe den Lock selbst steuern? Schlägt der Aufruf der Funktion aus irgend einem Grund fehl (Lock nicht erhalten, Serverprobleme, Datenverbindung nicht da, etc), wird dies nach dem Aufruf ausgewertet. Die Funktion soll nur versuchen das Zeug loszuwerden.
Was ich auch noch festgestellt habe, var Parameter in TuDies(var _UID : Integer) können nicht aus der anonymen Methode genutzt werden, daher habe ich Varianten einbauen müssen:
Code:
function ToDies(var _UID : Integer) : Boolean;
begin
Result := FDB.Call(procedure(var Err: ErrorStruct; var _ID : Integer)
begin
FDB.ToDies(_ID,err);
end,_UID);
end;
Jetzt muss ich geistig nur noch den Zusammenhang zu deinem Closure-Record hinbekommen.