PHP Forum

PHP Forum (http://www.selfphp.de/forum/index.php)
-   MySQLi/PDO/(MySQL) (http://www.selfphp.de/forum/forumdisplay.php?f=22)
-   -   result nach update (http://www.selfphp.de/forum/showthread.php?t=24612)

Lochmuehle 08.03.2012 00:16:12

result nach update
 
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 08.03.2012 12:06:31

AW: result nach update
 
wie wär's mit lock table ;-)

Lochmuehle 08.03.2012 12:17:59

AW: result nach update (Semaphor)
 
Zitat:

Zitat von derNichtGlaubt (Beitrag 143050)
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 08.03.2012 12:30:20

AW: result nach update
 
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 08.03.2012 12:47:18

AW: result nach update
 
Zitat:

Zitat von derNichtGlaubt (Beitrag 143052)
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 08.03.2012 13:27:46

AW: result nach update
 
Zitat:

Zitat von Lochmuehle (Beitrag 143053)
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 09.03.2012 02:05:58

AW: result nach update
 
Hi

Zitat:

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
Zitat:

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!


Alle Zeitangaben in WEZ +2. Es ist jetzt 16:32:14 Uhr.

Powered by vBulletin® Version 3.8.3 (Deutsch)
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.