Laufende Transaktion erkennen

[mkinzler]

Logging ist aber was anders als Locking

[mquadrat]

Wir benutzen für unser Programm nen eigenen TCP Server, der ne Liste mit allen gerade in Bearbeitung befindlichen Datensätzen hält. Die Locks in die Datenbank zu legen wäre natürlich auch eine Möglichkeit. Muss man halt drauf achten, dass die Transaktionen mit denen gelockt / der Lock überprüft werden nur so kurz wie möglich laufen.

[hoika]

Hallo HeinzJ,

das hast du was falsch verstanden.
Es geht um das Sperren (Locken) von Datensätzen,
nicht Protokollieren (Loggen).


Heiko

[Hansa]

Zitat von hoika:

Hallo IBExpert,

basierend auf dem Entwickler-Artikel (6/2003) ?
welche Zugriffskomponente ?

Der Artikel basiert aber auf FB 1.5, wenn nicht sogar 1.0. WITH LOCK gabs damals nicht und es hieß/heißt immer zumindest "Locking braucht man nicht für IB / FB". Ich sehe das allerdings nicht so. Früher habe ich das immer so gemacht : User1 editiert Datensatz. Jetzt fängt User2 an, genau denselben Datensatz auch zu editieren. DeddyH's Frage läuft wohl auch auf diese Konstellationen hinaus. Ich bin deshalb hingegangen und habe den DS vor dem Speichern erst mal gesperrt, dann neu gelesen. Kennt einer noch die BTree-Isam/Shell von Ralf Nagel/Enz (jetzt umgebaut als Flashfiler) ? Man hatte da drei Puffer für Datensätze : Workbuffer, Savebuffer und noch einen Dritten. Der Workbuffer war hierbei der gerade editierte Datensatz. Hat der sich von dem auf der Platte unterschieden (war deshalb eben sicherheitshalber gelockt und neu gelesen worden), dann konnte man die Felder einzeln auslesen und bearbeiten. Felder gezielt aktualisieren und fertig.

Beim Lagerbestand bin ich z.B. hingegangen und habe die durch gleichzeitigen Zugriff eventuell entstehenden Differenzen im Programm ermittelt und dann eben automatisch ausgeglichen und abgespeichert, dann Lock entfernt. Bsp.: Menge 10, User1 bucht Menge 1 ab, von der User2 (noch) nichts weiß, der hat immer noch auf seinem Bildschirm 10 stehen, sind aber bereits nur 9. Jetzt bucht User2 Menge 2 ab. Ergibt aus Sicht von User2 8. In Wirklichkeit sind es aber nur noch 7. Wenn der jetzt speichert, dann ist der Bestand um 1 höher, als er tatsächlich ist. Es ist zwar ein seltener konstruierter Fall, aber so etwas kann vorkommen. Mit geschickter Nutzung der Transaction-Isolation-Levels ist es mir zwar gelungen, das wasserdicht zu machen, aber so wie beim beschriebenen Lagerbestands-Problem habe ich es nicht hingekriegt. Es ist noch nicht komfortabel genug, so wie vorher gewöhnt.

Jetzt ist die Frage : was habe ich übersehen, bzw. nicht verstanden oder geht das Verhalten wie beschrieben nur mit Locking, wie vorher auch ? Das mit dem Workbuffer, Savebuffer usw. wird doch zumindest intern in IB/FB mit dem BDR (Back Difference Record) realisiert. Nur, ich kenne keinen, der da vom Programm her dran kommt und das Ding auswerten kann.

Zitat von IBExpert:

ich mach meistens mein eigenes locking, also im prinzip wie hier besprochen...

Und wie genau ? Hier wurde viel Durcheinander besprochen. Logging, Locktable...

[hoika]

Hallo Hansa,

im betreffenden Entwickler-Artikel wurd mit einer eigenen Lock-Table gearbeitet.
Dort steht Tabellenname/Id / DBId/ LockDatum/Zeit / Lock-User usw. drin.

Bevor das Programm einen Datensatz bearbeiten kann, muss es erst mal
die DBId in die LockTable packen (per unique index geht das nur einmal).

Das nette daran ist, dass man feststellen (und anzeigen) kann,
wer den Datensatz gerade sperrt.

Der Trick bestand ausserdem daran, das LockDatum per Timer immer wieder zu aktualisieren.


Heiko

[Hansa]

Keine Angst, habe den Artikel schon hier liegen. Aber nicht umgesetzt, weil zumindest Teile davon überholt sind. IMHO ist durch das neuere WITH LOCK das alles überflüssig. Oder eben auch nicht ? Das ist die Frage. Insbesondere, wie das mit dem Lagerbestand so geht, wie früher auch. Es kann doch fast nicht sein, dass mit einer noch aus DOS stammenden Datenbank mehr hinzukriegen ist, als mit FB Jahrgang 2008.

[hoika]

Hallo,

naja das With Lock musst du ja trotzdem machen,
aber doch erst, wenn wirklich geändert wird,
sonst blockierst du ja den Datensatz.

Table.Edit (Paradox) ist ja das gleiche wie

StartTransaction
Update Table Set Id=Id

// warten

Commit


Heiko

[Hansa]

Bei meinem Modell eben nicht. Die DS werden gelesen (natürlich mit dem richtigen Isolation-Level). Sagen wir zwei Stück. Die werden dann von 2 Usern editiert. Nur beim Abspeichern soll kurz der aktuelle Platten-DS gelockt und neu gelesen werden. Damit sollen keinerlei Änderungen für 2. Benutzer für diese kurze Zeit eben möglich sein. Bei Abweichungen aktueller DS auf Platte <-> dem fertig editierten und abzuspeichernden sollen die Differenzen ausgelesen und automatisch ausgeglichen werden. Dann war der eine eben schneller. Die Differenz wird programmtechnisch ausgeglichen und fertig.

Es ist kein Problem, immer den letzten den von ihm sichtbaren aktuellen Zustand herstellen zu lassen, der aber durch die vorherige Änderung falsch ist. Bei FIBPlus gibts ja im OI sogar zwei einzustellende Transaktionen (Transaction und UpdateTransAction) und das geht damit fast wie gewollt, aber nur fast. Die sagen, die eine läuft kurz und die andere lang usw. und das würde gehen. So einfach aber nicht. Wenn man zumindest den letzten schreibenden darauf hinweisen könnte, dass das nicht geht, weil der DS zwischenzeitlich bereits geändert wurde. Dann gehts aber wieder neu los. Wie die letzte Eingabe rückgängig machen und nur die ? Mit Savepoints könnte es vielleicht gehen. Ich sehe, muss mich nochmals intensiver mit Netzwerk auseinandersetzen.

schlägt roter Kasten plötzlich sogar zu früh zu ?

[mkinzler]

Und das Verhalten ist doch bei erneuten Lesen mit Lock möglich.

[DeddyH]

Nach langem Herumprobieren scheint es mir tatsächlich die eleganteste Möglichkeit zu sein, eine eigene Locking-Tabelle einzuführen wie bereits weiter oben beschrieben. Ein Select mit der "WITH LOCK"-Option tut zwar wie erwartet, führt aber zu dem unschönen Nebeneffekt, dass der Start einer 2. Instanz so lange warten muss, bis die Sperre aufgehoben wurde, da ich im OnCreate die vorhandenen DS aufliste. Das Ganze ist auch hier beschrieben: http://www.firebirdfaq.org/faq182/.
Danke für die zahlreichen Antworten und Denkanstöße.