Timer oder Thread für nebenläufigen DB-Code

[hoika]

Hallo #,

ich will in meine DB nun endlich mal auch pessimistische Sperren einbauen,
dass heisst, bevor der Nutzer was ändern will, muss das Programm prüfen,
ob nicht schon jemand anderes dran arbeitet.

Bitte keine Info, dass es anders geht,
ich mache das so wie es jeztzt folgt (da war mal nen guter Artikel im Entwickler).

Das Programm führt eine Sperrtabelle mit, wo jeder gesperrte Datensatz
mit seiner ID (prim. key) drinsteht.
Zusätzlich wird auch die Uhrzeit der Sperrung eingetragen,
und diese Uhrzeit wird ständig (alle x Minuten) aktualisiert.
Damit kann man sich gegen Sperren abgestürzter Programme sichern
(veraltete Sperren werden gelöscht).

Nun zum Problem.
Der Ansatz im Artikel benutze einen Timer zur Aktualisierung.

Würde das über einen Thread einfacher / besser sein.
der Thread würde sich "starten", die Aktualisierung machen
und wieder schlafenlegen.

Was meint ihr ?


Danke im voraus
Heiko

[Chewie]

Ein normaler Timer läuft im gleichen Thread wie das Hauptprogramm, da ist also nix mit Nebenläufigkeit! Mach einen Thread, der tut, was er tun muss, wartet und wieder arbeitet.

[mkinzler]

Zitat:

Würde das über einen Thread einfacher / besser sein.
der Thread würde sich "starten", die Aktualisierung machen
und wieder schlafenlegen.

Auf jeden Fall,m da hier die Sperre nur so lange aktiv ist wie benötigt.

BTW.: Pessimistische Sperren sind bei FB sehr selten nötig. Ab FB2.0 gibt es auch die direkte Unterstützung dafür in SQL!

Warum BDE für FB?

[Jürgen Thomas]

Zitat:

Zitat von hoika

Würde das über einen Thread einfacher / besser sein.
der Thread würde sich "starten", die Aktualisierung machen
und wieder schlafenlegen.

Ich bin mit meiner Konzeption noch nicht ganz so weit wie Du, habe mir aber bereits Gedanken gemacht.

Nach meiner Vorstellung sollte ein Thread nur dann verwendet werden, wenn er längere Arbeiten zu erledigen hat, während der der Benutzer mit anderen Arbeiten im gleichen Programm fortfahren kann. Wenn Deine Aktualisierung (sehr) viele Datensätze betrifft, dann kann ein Thread sinnvoll sein - das müsstest Du dann ausprobieren.

Wenn es aber nur um die Sperrvermerke geht, handelt es sich eigentlich maximal um 2 Update-Befehle (veraltete Sperrvermerke aufheben, den aktuell gewünschten setzen); dann dürfte der Timer besser sein.

Gruß Jürgen

PS. Bitte teile mit, wozu Du Dich entscheidest.

[hoika]

Hallo,

bde, weil is halt uraltes Programm.
Ich bin ja froh, dass es wenigstens nicht mehr Paradox ist :wall:

Bin ja dabei, umzustellen, geht aber nicht so einfach und kostet
nen Haufen Zeit ;(

Pessimistische Sperre, damit das Programm sagt
"Neee, die Personaldaten von Meier befummelt gerade die Frau Müller"

Thread gefällt mir auch besser,
ist aber wohl schwerer zu implementieren,
mal sehen.



Heiko

[mkinzler]

Ich habe nachgeschaut die expliziten Sperren in DSQL geht schon ab Version 1.5 nicht erst ab 2. Du kannst also die Sperren direkt in der Sql-Abfrage anlegen.

[hoika]

Hallo ,

ich weiss,
aber ich will ja schon vor der (Update)-Abfrage sperren,
also direkt in der Anwendung.

Es geht ja wie gesagt nicht um das wie sperren,
sie wie das nebenläufige hinbekommen.

Ah ja, und stellenweise haben die Herren Kunden auch noch IB6
und wollen nicht wechseln (nene, läuft j alles ..)

Heiko

[DGL-luke]

ja, warum nicht im thread.

Delphi-Quellcode:

procedure TLockThread.Execute;
begin
  UpdateLocks;
  sleep(1000 * 60) //1 Minute schlafen
end;

wenn du auf ein feld zugreifst, übergibst du dem thread alle nötigen daten, startest ihn, und wenn du fertig bist, beendest du ihn, und gibst die locks wieder frei.

[mkinzler]

Zitat:

Ich weiss,
aber ich will ja schon vor der (Update)-Abfrage sperren,
also direkt in der Anwendung.

Geht doch

SQL-Code:

select ... from ..
for update ..
with lock ...;

sperrt schon beim Select den Datensatz bis zur Ende der Transaktion.

[hoika]

Jepp,

so hatte ich mir das gedacht,
Problem ist, dass ich aber immer noch mit der BDE rumfummeln muss.

Zumindest der Lock-Code soll aber schon mit UIB oder ZEOS laufen,
also brauche ich auch ne 2. Connection .

Und die sollte natürlich nicht mit jedem neuen Thread
neu aufgebaut werden.

Der Teufel liegt im Detail ;(


Heiko