phpBB.de

Hi

ich will meine Datenbanken meiner Seite komplett umstellen, doch wann ist dass sinnvoll und wann sollte ich es besser lassen
was kann alles schiefgehen?
was kann ich falsch machen?

zur umstellung:
ich möchte umstellen, da aktuell aufträge teilweise doppelt ausgeführt werden, dadruch dass zwei user zur gleichen zeit ne php datei aufrufen..., dies möchte ich mithilfe von transaktionen in innodb verhindern und ggf. durch ein rollback doch nicht aktualisieren

aber wie gesagt, will nicht einfach die Tabellen konvertieren und schauen was passiert, sonsdern zumindestens ein wenig vorbereitet sein, wäre also über hilfe dankbar

mfg
topo

michael-88 hat geschrieben:zur umstellung:
ich möchte umstellen, da aktuell aufträge teilweise doppelt ausgeführt werden, dadruch dass zwei user zur gleichen zeit ne php datei aufrufen..., dies möchte ich mithilfe von transaktionen in innodb verhindern und ggf. durch ein rollback doch nicht aktualisieren

Wäre dies nicht sinnvoller dies über eine Tabellensperre für die Zeit der Bearbeitung durch die php-Datei zu erreichen?

Grundsätzlich sind die Transaktionen ja für solche oder ähnliche Fälle mit Race Conditions oder kritische Daten erschaffen worden. Wann immer du verhindern willst, dass Daten in einen inkonsistenten Zustand gelangen, weil mehrere Updates in Folge entweder vollständig oder gar nicht durchgeführt werden sollen solltest du innoDB nutzen.

Du solltest dann den Transaktionstyp aber auf serializable stellen, auf die Weise wirst du zwar u.U. stark gebremst, aber die Transaktionen werden nicht mehr gleichzeitig ausgeführt. Ansonsten hätte die Umstellung für dich aber überhaupt keine Vorteile: Es wird bei den übrigen Transaktionstypen zwar sichergestellt, dass eine Gruppe von Daten entweder im Zustand vor oder im Zustand nach der Bearbeitung durch den ersten Benutzer ist wenn ein weiterer Benutzer zugreifen will (Ausnahme: Read uncommited, da kann man auch inkonsistente Daten lesen), aber wenn dann beide die gleiche Aktion durchführen weil sie von den ursprünglichen Daten ausgehen hast du ja nichts gewonnen. Serializable blockiert den Ablauf bis die andere Transaktion beendet ist und führt ihn erst anschließend durch, wenn jemand anderes also gleichzeitig die Daten bearbeiten will, wird erzwungen, dass einer später dran ist - wenn du dann während der Transaktion prüfst, ob die Daten schon bearbeitet wurden kann nichts mehr passieren da du zwangsläufig entweder vorher oder nachher dran bist.

Je nach konkrentem Problem reicht es aber auch vielleicht aus, die jeweilige Tabelle während deiner Aktion zu sperren - sämtliche parallel ausgeführten Abfragen sollten dann ins Leere führen, bzw. du bekommst nur mit einem Client gleichzeitig das Lock.

Wenn es nur darum geht, zu verhindern, dass zwei Benutzer gleichzeitig die selbe Aktion ausführen, geht das auch mit MyISAM. Dazu einfach beim WHERE die alten Werte mitgeben und mit mysql_affected_rows() prüfen, ob der Datensatz geändert wurde.

Beispiel: Es soll der 1000ste Besucher ermittelt werden; dabei soll verhindert werden, dass zwei Besucher als der 1000ste erkannt werden, wenn diese im selben Moment die Seite aufrufen. Dazu wird zuerst der aktuelle Zählerstand mit SELECT abgerufen (z.B. 999) und dann das Update mit dem ausgelesenen Wert als WHERE Bedingung ausgeführt: Wenn mysql_affected_rows() danach 1 ausgibt, wurde der Wert von 999 auf 1000 erhöht und der aktuelle Besucher bekommt seinen Gewinn. Wenn jedoch 0 zurückgegeben wird, wurde der Wert in der Datenbank zwischenzeitlich von einem anderen Prozess geändert und der aktuelle Benutzer kann nicht der 1000ste sein.

Siehe: http://dev.mysql.com/doc/refman/5.0/en/ ... tions.html