result nach update

[Lochmuehle]

Hallo zusammen,

stehe grade auf dem Schlauch...
wie bekomme ich nach
UPDATE meinetabelle SET eintrag=eintrag+1 WHERE meinfeld='xyz' LIMIT 1
den neuen Wert von eintrag OHNE einen SELECT im nächstem Auftrag zu schreiben?

Anwendung: mehrere Prozesse greifen auf diesen Wert zu, erhöhen ihn und sollen den neuen Wert verwenden. Prozess A erhöht von 5 auf 6 und soll 6 verwenden, Prozess B erhöht von 6 auf 7 und soll 7 verwenden. Prozess A soll zwischen erhöhen und abfragen nicht von B unterbrochen werden weil dann beide den Wert 7 verwenden würden.

Vielen Dank für eure Hilfe.
Ernest

[derNichtGlaubt]

wie wär's mit lock table ;-)

[Lochmuehle]

Zitat von derNichtGlaubt

wie wär's mit lock table ;-)

Das wäre für mich die zweitbeste Lösung. Ich komme aus der Welt der assembly programmierung. Schon der 80386 kann eine Speicherzelle lesen, ändern, schreiben und das Ergebnis in AX liefern, alles in einem Befehl. Das Thema nennt sich Semaphor. Ich hatte gehoft, mysql würde hier für eine praktische kleine Lösung bieten. Das Locken scheint mir recht aufwendig für so eine einfache standard-Aufgabe. Aber wenn es nicht anders geht...dann muss ich wohl.

Ernest

[derNichtGlaubt]

Lock table ist nicht aufwendig sondern sollte - eigentlich zwingend - vor jedem Schreibprozess in eine Datenbank erfolgen, eben um Kollisionen verschiedener Prozesse zu vermeiden. Und ob Du nun Lock → Update → Unlock oder Lock → Update → Select → Unlock machst, macht, auf gut österreichisch "das Kraut auch nicht fett".

p.s.: ... das mit der Assemblerprogrammierung, möglichst kurzer, effizienter Code, kann ich nachvollziehen, hab' vor ~30 Jahren auch noch DEC-Tape-Treiber, damals für ne PDP11/34 in Assembler geschrieben ....

[Lochmuehle]

Zitat von derNichtGlaubt

Lock table ist nicht aufwendig sondern sollte - eigentlich zwingend - vor jedem Schreibprozess in eine Datenbank erfolgen, eben um Kollisionen verschiedener Prozesse zu vermeiden. Und ob Du nun Lock → Update → Unlock oder Lock → Update → Select → Unlock machst, macht, auf gut österreichisch "das Kraut auch nicht fett".

p.s.: ... das mit der Assemblerprogrammierung, möglichst kurzer, effizienter Code, kann ich nachvollziehen, hab' vor ~30 Jahren auch noch DEC-Tape-Treiber, damals für ne PDP11/34 in Assembler geschrieben ....

dann werde ich dran gehen müssen.
Aber, lock vor jedem schreiben? Auch wenn ich Records hinzufüge?
Lock / unlock doch nur wenn ein race-condition beim gleichzeitigem Zugriff auf die gleiche Records auftreten kann? Alles andere soll der mysql engine abfangen (imho).

p.s. mir haben 6502 und Z80 am meisten Spaß gemacht. Spätestens beim Pentium war der Spaß vorbei.

[derNichtGlaubt]

Zitat von Lochmuehle

dann werde ich dran gehen müssen.
Aber, lock vor jedem schreiben? Auch wenn ich Records hinzufüge?
Lock / unlock doch nur wenn ein race-condition beim gleichzeitigem Zugriff auf die gleiche Records auftreten kann? Alles andere soll der mysql engine abfangen (imho).

Die Mysql engine verwaltet die Lock-Anfragen(!)

Lock beim Schreiben? IMMER

Ich nutze Lock aber auch beim Abfragen, da ich bereits beim Schreiben(input/update) immer einen Zeitstempel mitschreibe, den ich mir bei der Abfrage immer mitausgeben lasse, d.h. ich weiß immer von welchem Zeitpunkt die Daten, respektive deren Änderung(en) stammen (das kann beim Rückverfolgen sehr praktisch sein...)

[Ckaos]

Hi

Prozess A soll zwischen erhöhen und abfragen nicht von B unterbrochen werden weil dann beide den Wert 7 verwenden würden.

Ich weis ja nicht was du genau machst, aber ich glaube nicht das du bei nem update/select
da riesen probleme bekommen wirst. Beide frühstücke ich in milisekunden ab.
Desweiteren mal weiter in der Doku schauen

Wenn Sie das Schlüsselwort LOW_PRIORITY angeben, wird die Ausführung von UPDATE verzögert, bis kein Client mehr aus der Tabelle liest.

und dann gibts da ja auch noch
Stored Procedures, Trigger und Views
Also... ran ans lesen ;)

mfg

CKaos
C64 Generation!