[PHP/MySQL] - commit klappt nicht

[alcaeus]

Zitat von fkerber:

Und es gibt auch keinen feinkörnigeren Lock als gleich die ganze Tabelle?

Habs mir gerade nochmal angesehn: nein. Row-Level-Locks werden nur von InnoDB unterstuetzt, wenn du dich auf das Locking der DB verlaesst.
Bei READ gibt es die Moeglichkeit, so genannte "non-conflicting inserts" zu erlauben, write-Locks gelten aber immer fuer die ganze Tabelle. Da du hier aber eine relativ kurze und unkritische Critical Section hast, duerfte ein Table-Lock erst bei hoher Last auffallen. Du hast schliesslich keine Key-Updates, und wenn die Where-Bedingung von Update und Select als gesamter Key vorhanden sind, gibt es da wirklich keine Performance-Probleme.

Greetz
alcaeus

[fkerber]

Hi,

Zitat von alcaeus:

Habs mir gerade nochmal angesehn: nein. Row-Level-Locks werden nur von InnoDB unterstuetzt, wenn du dich auf das Locking der DB verlaesst.

danke für deine Mühe. Es ist ne InnoDB, aber ich vermute, deine Aussage sagt, das ist nur was DB-internes, was ich von außen nicht anleiern kann?


Liebe Grüße,
Frederic

[alcaeus]

Zitat von fkerber:

danke für deine Mühe. Es ist ne InnoDB, aber ich vermute, deine Aussage sagt, das ist nur was DB-internes, was ich von außen nicht anleiern kann?

Korrekt - das betrifft nur die von InnoDB selbst initiierten Locks.

Greetz
alcaeus

[fkerber]

Hi!

Gut, soweit

Jetzt sehe ich nur ein Problem:
Die Doku sagt:

Zitat:

Die korrekte Vorgehensweise bei der Verwendung von LOCK TABLES in Verbindung mit transaktionssicheren Tabellen wie InnoDB besteht darin, AUTOCOMMIT = 0 zu setzen und UNLOCK TABLES erst dann aufzurufen, wenn die Transaktion explizit übergeben werden soll. Wenn Sie LOCK TABLES aufrufen, setzt InnoDB intern eine eigene Tabellensperre. Auch MySQL setzt eine eigene Tabellensperre. InnoDB hebt seine Sperre beim nächsten Commit-Vorgang auf; damit MySQL seinerseits die Sperre aufhebt, müssen Sie UNLOCK TABLES aufrufen. Sie sollten AUTOCOMMIT = 1 nicht setzen, weil InnoDB dann seine Tabellensperre direkt nach dem Aufruf von LOCK TABLES aufhebt; auf diese Weise kann es zu einer vollständigen Sperrung kommen. Beachten Sie, dass bei AUTOCOMMIT = 1 die InnoDB-Tabellensperre überhaupt nicht gesetzt wird, damit ältere Anwendungen sich nicht versehentlich vollständig ausschließen.

D.h. doch ich muss alles so machen wie bisher auch und zusätzlich das LOCK TABLES da rein. Rettet das mich dann wirklich? Oder fliegt mir die Sache dann trotzdem um die Ohren? Weil das Select wäre ja weiter dann in der Transaktion da drin?!

Grüße, Frederic

[alcaeus]

Moin,

ganz kurz das Prozedere:

SQL-Code:

SET AUTOCOMMIT = 0;
LOCK TABLES course_registrations WRITE;
UPDATE course_registrations...;
SELECT active FROM course_registrations...;
UNLOCK TABLES course_registrations;
SET AUTOCOMMIT = 1;

Ich bin mir grad nicht ganz sicher wie das Verhalten bei autocommit = 0 ist - eventuell musst du nach dem Update aber noch vor dem Select einen Commit machen bzw. auch vor dem Update noch eine Transaktion oeffnen. Ganz aussen rum ist der autocommit, dann dein Lock, anschliessend die Queries die du ausfuehren willst.

Beachte aber, dass du den Unlock direkt nach dem Select machst und noch bevor du die Daten verarbeitest, damit du die Tabelle nicht laenger als noetig benutzt. Beachte ausserdem dass du vor dem Unlock keine Tabelle benutzen kannst die nicht vorher gelockt wurde.

Greetz
alcaeus

[mkinzler]

Das Transaktionshandling bei MySQL erscheint mir etwas umständlich und suboptimal

[alcaeus]

Zitat von mkinzler:

Das Transaktionshandling bei MySQL erscheint mir etwas umständlich und suboptimal

Du solltest wissen dass solche Aussagen ohne Begruendung wertlos sind. Wenn man das System verstanden hat ist dieses Vorgehen vollkommen normal.

Greetz
alcaeus

[mkinzler]

Sorry dass ich mir überhaupt erlaubt habe etwas zu schreiben.

[fkerber]

Hi!

Irgendwo muss ein Haken sein:

PHP-Quellcode:

   $db -> autocommit(false);
   $db -> query("LOCK TABLES course_registrations WRITE");
   
   $sql = $db -> prepare('UPDATE course_registrations SET active = NOT active WHERE participantId=? AND courseId=?');
   $sql -> bind_param('ii', $participantID, $courseID);
   $sql -> execute();
   
   $sql2 = $db->prepare('SELECT active FROM course_registrations WHERE participantId=? AND courseId=?');
   $sql2 -> bind_param('ii', $participantID, $courseID);
   $sql2 -> execute();

   $db -> query("UNLOCK TABLES course_registrations");

   $sql2 -> bind_result($active);
   $sql2 -> fetch();

   if ($db -> commit()) {
      
   } else {
      echo $active;      
      echo "ARGH";
   }


   //$db -> query("UNLOCK TABLES course_registrations");

   
   $db -> autocommit(true);

Egal an welchen der beiden Stellen das UNLOCK steht - das Ergebnis ist immer ein ARGH...


Grüße, Frederic

[alcaeus]

Zitat von mkinzler:

Sorry dass ich mir überhaupt erlaubt habe etwas zu schreiben.

Komm, du solltest besser wissen als auf beleidigt zu spielen
Es ist nunmal einfach etwas "unlogisch", "kompliziert", "doof", "ungeschickt", was auch immer zu nennen. Wenn du die letzten paar PHP-Themen hier in der DP ansatzweise verfolgt hast weisst du auch was dabei rauskommt: irgendwer liest es und nimmts fuer bare Muenze.

Es spricht nichts gegen eine Diskussion ueber das Thema - aber wenn dann bitte mit Argumenten.

Zum Thema:
1. Den fetch() solltest du vor dem Unlock ausfuehren.
2. Die Logik hat nen kleinen Denkfehler: wenn autocommit = 0 musst du das Update-Statement mit nem Commit bestaetigen. Das musst du vor dem Select machen, ansonsten ist die Aenderung ja noch nicht in der DB.

Greetz
alcaeus