hallo
ich arbeite mich gerade in transaktionen(innoDB) bei mysql ein und ich wollte fragen ob jemand ein paar gute tuts kennt?
falls ihr ein paar tipps habt, her damit
mfg Roland
Mysql und transaktionen
gepostet vor 18 Jahre, 8 Monate von planetenkiller
gepostet vor 18 Jahre, 8 Monate von Kampfhoernchen
Zu Transaktionen fällt mir jetzt kein Tut ein.
Aber ein Wort zu InnoDB: Es ist doch um vieles langsamer als andere Transaktionsorientierte Systeme (etwa MaxDB oder Postgres). Wenn du die Möglichkeit hast, eines von diesen Systemen einzusetzen, würde ich dazu raten.
Aber ein Wort zu InnoDB: Es ist doch um vieles langsamer als andere Transaktionsorientierte Systeme (etwa MaxDB oder Postgres). Wenn du die Möglichkeit hast, eines von diesen Systemen einzusetzen, würde ich dazu raten.
gepostet vor 18 Jahre, 8 Monate von planetenkiller
ich möchte das mal mit innodb machen, den die anderen systeme kenne ich gar nicht.
aber irgendwie kapiere ich das nicht.
ich möchte mit den transaktionen verhindern das gleichzeitig zwei prozesse(user klickt sehr schnell auf bauen, also 2 prozesse würden bauen) ein gebäude bauen. ich dachte ich lege eine neue tabele an wo alle user drinstehen(spalten: user_id, bauen_1). wenn ich jetzt bauen will starte ich die transaktion mit
BEGIN
und durch
SELECT * FROM user_bauen WHERE user_id = 1 IN SHARE MODE
ist der datensatz gesperrt. wenn bauen_1 nicht 1 ist, kann ich mit
UPDATE user_bauen SET bauen_1 = 1
bauen_1 auf 1 setzen, was sagt das ich gerade baue.
wenn jetzt der zweite prozess versucht zu bauen muss er warten bis die transaktion des ersten prozesses fertig ist, oder? und da ich ja bauen_1 auf 1 gesetzt habe, darf der zweite prozess nicht bauen.
könnte ich das so realisieren, was meint ihr?
mfg Roland
aber irgendwie kapiere ich das nicht.
ich möchte mit den transaktionen verhindern das gleichzeitig zwei prozesse(user klickt sehr schnell auf bauen, also 2 prozesse würden bauen) ein gebäude bauen. ich dachte ich lege eine neue tabele an wo alle user drinstehen(spalten: user_id, bauen_1). wenn ich jetzt bauen will starte ich die transaktion mit
BEGIN
und durch
SELECT * FROM user_bauen WHERE user_id = 1 IN SHARE MODE
ist der datensatz gesperrt. wenn bauen_1 nicht 1 ist, kann ich mit
UPDATE user_bauen SET bauen_1 = 1
bauen_1 auf 1 setzen, was sagt das ich gerade baue.
wenn jetzt der zweite prozess versucht zu bauen muss er warten bis die transaktion des ersten prozesses fertig ist, oder? und da ich ja bauen_1 auf 1 gesetzt habe, darf der zweite prozess nicht bauen.
könnte ich das so realisieren, was meint ihr?
mfg Roland
gepostet vor 18 Jahre, 8 Monate von schokofreak
Nein du machst das so:
Transact
select Rohstoffe from user;
Select Gebäude from User
berechnest ob genügend rohstoffe für eine Erweiterung vorhanden sind
Update Rohstoffe - benötigte Rohstoffe
Update Gebäude + 1
Commit
Das ist schon alles; die transaktion verhindert dass da etwas falsch laufen kann.
Gruss
Transact
select Rohstoffe from user;
Select Gebäude from User
berechnest ob genügend rohstoffe für eine Erweiterung vorhanden sind
Update Rohstoffe - benötigte Rohstoffe
Update Gebäude + 1
Commit
Das ist schon alles; die transaktion verhindert dass da etwas falsch laufen kann.
Gruss
gepostet vor 18 Jahre, 8 Monate von Kampfhoernchen
Kommt auf Transaktionslevel an. In diesem Falle empfehle ich einen "Repeatable Read"
gepostet vor 18 Jahre, 8 Monate von planetenkiller
was ist Transact?
gepostet vor 18 Jahre, 8 Monate von planetenkiller
was passiert eingenlich wenn wärend einer transaktion die verbindung geschlossen wird, also wenn ich jetzt wärend dem laden der seite den browser schliesse? macht er dan ein ROLLBACK?
mfg Roland
mfg Roland
gepostet vor 18 Jahre, 8 Monate von schokofreak
jup
gepostet vor 18 Jahre, 8 Monate von Kampfhoernchen
Jop. Kommt während der "Timeout"-Zeit (i.d.R 60 sek) kein weiterer Request auf dieser Connection, wird die Transaktion zurückgesetzt.
gepostet vor 18 Jahre, 8 Monate von Chojin
Wer macht den bitte Transactions über mehrere Seitenaufrufe?
Wenn ihr mich fragt wird die Transaktion abgearbeitet sobald die Anweisung dazu kommt. Generell ist es egal ob dann ein Browser da ist der die ausgegebene seite noch vollständig anzeigt oder nicht..
reg4rds
chojin
Wenn ihr mich fragt wird die Transaktion abgearbeitet sobald die Anweisung dazu kommt. Generell ist es egal ob dann ein Browser da ist der die ausgegebene seite noch vollständig anzeigt oder nicht..
reg4rds
chojin
gepostet vor 18 Jahre, 8 Monate von The-Winner
Generell ist es egal ob dann ein Browser da ist der die ausgegebene seite noch vollständig anzeigt oder nicht
Wenn ignore_user_abort nicht an ist, wird das php Skript abgebrochen wenn der user das laden der Seite abbricht.
->Kann zu Fehlern führen
gepostet vor 18 Jahre, 8 Monate von planetenkiller
Wenn ignore_user_abort nicht an ist, wird das php Skript abgebrochen wenn der user das laden der Seite abbricht.
ohh ja, davon kann ich ein liedchen singen.
mfg Roland
gepostet vor 18 Jahre, 8 Monate von Chojin
Sprich: ignore_user_abort sollte sowieso angeschalten sein weil man sonst in größere probleme kommt und transaktions haben ohne diese funktion nichts mit dem Client browser zu tun.
(hatte recht) :mrgreen:
reg4rds
chojin
(hatte recht) :mrgreen:
reg4rds
chojin
gepostet vor 18 Jahre, 8 Monate von Kallisti
Original von Chojin
Sprich: ignore_user_abort sollte sowieso angeschalten sein weil man sonst in größere probleme kommt und transaktions haben ohne diese funktion nichts mit dem Client browser zu tun.
(hatte recht) :mrgreen:
reg4rds
chojin
Es ist aber per default aus.
gepostet vor 18 Jahre, 8 Monate von schokofreak
ignore_user_abort funktioniert nicht zuverlässig.
Sprich ich hatte auch schon probleme damit, dass bei groben Hängern einfach trozdem abgebrochen wurde.
Deshalb lautet für mcih die Devise. Weiso soll der Webserver das machen? Ist Aufgabe der DB.
Somit: Mit transaktionen arbeiten; UserAborts dürfen ruhig durchgeführt werdena uf Webserver ebene.
Die Transaktion besorgt das Rollback dann von alleine.
AUSSER man manipuliert irgendwo noch Daten unabhängig von der DB (beispielsweise Dateien) - aber wer das im grossen Stile (und bei User Aktionen; nicht Admin Aktionen) tut ist eh selbst schuld.
Gruss
Sprich ich hatte auch schon probleme damit, dass bei groben Hängern einfach trozdem abgebrochen wurde.
Deshalb lautet für mcih die Devise. Weiso soll der Webserver das machen? Ist Aufgabe der DB.
Somit: Mit transaktionen arbeiten; UserAborts dürfen ruhig durchgeführt werdena uf Webserver ebene.
Die Transaktion besorgt das Rollback dann von alleine.
AUSSER man manipuliert irgendwo noch Daten unabhängig von der DB (beispielsweise Dateien) - aber wer das im grossen Stile (und bei User Aktionen; nicht Admin Aktionen) tut ist eh selbst schuld.
Gruss
gepostet vor 18 Jahre, 8 Monate von schokofreak
Original von Chojin
Wer macht den bitte Transactions über mehrere Seitenaufrufe?
Wenn ihr mich fragt wird die Transaktion abgearbeitet sobald die Anweisung dazu kommt. Generell ist es egal ob dann ein Browser da ist der die ausgegebene seite noch vollständig anzeigt oder nicht..
Zumindest mit PHP Niemand.
Ansonsten kann es schon sinn machen.
Weiso schaut man die User-Registrierung nicht als Transaktion an?
Default-Rollback nach 1 Tag.
Sprich wenn der User nach einem Tag noch nicht fertig ist mit der Transaktion, so wird gerollbacked.
Wenn der User mitten in der Transaktion ist, so sieht er die bis jetzt erfassten Daten. ABER ein anderes Script sieht diesen User noch nicht.
Macht sehr wohl sinn... nur dass man sowas mit php wohl nicht sinnig realisieren kann. Es seie denn man implementiert eigenes Transaktions-Handling und baut sich gleich einen Workflow-Server.
Gruss
gepostet vor 18 Jahre, 8 Monate von Kampfhoernchen
oder man zeigt den Spieler nur an, wenn er die Aktivierung abgeschlossen hat (Sprich: Flag activation auf true setzen).
gepostet vor 18 Jahre, 8 Monate von schokofreak
Kampfhoernchen: Flags sind fehleranfällig; Transaktionen nicht
Man kann durch Transaktionen sehr viel Implementations-Komplexität reduzieren.
Aber wie gesagt, in PHP machen für mich Transaktionen über mehrere Requests keinen Sinn.
Wenn man in Java sowas macht, dann darf man dies nicht mit DB Transaktionen tun -> kann ja auch ne schicht höher n Transaktionshandling einbauen.
Gruss
Man kann durch Transaktionen sehr viel Implementations-Komplexität reduzieren.
Aber wie gesagt, in PHP machen für mich Transaktionen über mehrere Requests keinen Sinn.
Wenn man in Java sowas macht, dann darf man dies nicht mit DB Transaktionen tun -> kann ja auch ne schicht höher n Transaktionshandling einbauen.
Gruss
gepostet vor 18 Jahre, 8 Monate von Kampfhoernchen
Ich gehe dabei von PHP aus
gepostet vor 18 Jahre, 7 Monate von planetenkiller
ich habe da noch eine frage:
ich habe eine trabelle mit der spallte xy. ich habe da zwei zeilen, eine mit 100 und eine mit 200.
wenn ich jetzt select * from egal WHERE xy < 150 for update sende
bekomme ich die zeile mit dem wert 100
wenn ich wärend desen select * from egal WHERE xy < 245 for update sende wartet er, bis die obere transaktion fertig ist.
geht auch, das dan hallt einfach nur die zeile mit dem wert 200 zurückgegeben wird und die zeile mit dem wert 100 nicht weill sie geade in benutzung ist?
mfg Roland
ich habe eine trabelle mit der spallte xy. ich habe da zwei zeilen, eine mit 100 und eine mit 200.
wenn ich jetzt select * from egal WHERE xy < 150 for update sende
bekomme ich die zeile mit dem wert 100
wenn ich wärend desen select * from egal WHERE xy < 245 for update sende wartet er, bis die obere transaktion fertig ist.
geht auch, das dan hallt einfach nur die zeile mit dem wert 200 zurückgegeben wird und die zeile mit dem wert 100 nicht weill sie geade in benutzung ist?
mfg Roland
gepostet vor 18 Jahre, 7 Monate von Drezil
Original von planetenkiller
wenn ich wärend desen select * from egal WHERE xy < 245 for update sende wartet er, bis die obere transaktion fertig ist.
geht auch, das dan hallt einfach nur die zeile mit dem wert 200 zurückgegeben wird und die zeile mit dem wert 100 nicht weill sie geade in benutzung ist?
Ich würde sagen nein.
aber wenn du
select * from egal WHERE xy between 150 AND 245
machst, dann sollte es gehen.
Ich weiss nur nicht, inwieweit das deinem zweck entspricht..
aber eigentlich sind transaktionen relativ kurz, und da macht so ein kleines warten auf das lock bei vernünftiger programmierung nichts aus ..
oder du nimmst eben ein LOCK IN SHARE MODE, welches keinen exklusiven (write-lock) setzt.