gleichzeitige zugriffe auf die db

[yks]

hallo,

eine "grüne" frage...
ich hatte bei os400 (iseries) mal gelernt, daß keine gleichzeitigen zugriffe auf die db stattfinden sollten (muß nicht, aber könnte wohl probleme geben) - womit natürlich nicht die userzugriffe gemeint waren. nur inzwischen bekomme ich es nicht mehr zusammen, wie genau und warum das so war.

daher nun die frage bzgl der mysql-db :
gibt es diesen 'grundsatz' hier auch ? *vermute*
ist es demnach zb schlecht, wenn 2 admins gleichzeitig auf die db zugreifen ?
oder auf was genau bezieht sich das nochmal - und ist es bei mysql ebenso ?

überlegte mir gerade, ob es probleme für die phpbb-forums-db geben könnte, wenn ich über andere php dateien ebenfalls auf die db-daten zugreifen würde. ka warum verunsichert bin, denke eigentlich, an sich logisch, daß keine probleme geben sollte, solange die daten nur ausgelesen werden - beim schreiben wohl darauf ankommt, wie, etc, oder ?

danke + eiswürfel da laß, yks

[shwepsi]

hallo,

eine "grüne" frage...
ich hatte bei os400 (iseries) mal gelernt, daß keine gleichzeitigen zugriffe auf die db stattfinden sollten (muß nicht, aber könnte wohl probleme geben) - womit natürlich nicht die userzugriffe gemeint waren. nur inzwischen bekomme ich es nicht mehr zusammen, wie genau und warum das so war.

daher nun die frage bzgl der mysql-db :
gibt es diesen 'grundsatz' hier auch ? *vermute*
ist es demnach zb schlecht, wenn 2 admins gleichzeitig auf die db zugreifen ?
oder auf was genau bezieht sich das nochmal - und ist es bei mysql ebenso ?

überlegte mir gerade, ob es probleme für die phpbb-forums-db geben könnte, wenn ich über andere php dateien ebenfalls auf die db-daten zugreifen würde. ka warum verunsichert bin, denke eigentlich, an sich logisch, daß keine probleme geben sollte, solange die daten nur ausgelesen werden - beim schreiben wohl darauf ankommt, wie, etc, oder ?

danke + eiswürfel da laß, yks

100% sicher bin ich mir nicht, aber ich meine das die Zugriffe da alle nacheinander ablaufen.
Jeder sql Befehl kommt erstmal in eine Warteschleife, erst dann wird er ausgeführt. Doppelte Zugriffe werden somit verhindert.

[kellanved]

Synchronisierung paralleler (schreibender) Zugrifffe wird bei den heutzutage üblichen Systemen vom Datenbankprogramm selbst sichergestellt; MySql wurde für mehrere Nutzer zur gleichen Zeit entworfen.
Paralleler Zugriff ist daher kein Problem, bei längeren Skripten mit mehreren Datenbankabfragen sollte man schon vorsichtig sein.

[SD582]

Hi

Probleme gibt es grundsätzlich dann, wenn jemand (ein script) etwas aus der DB liest, verändert und dann schreibt. Und gleichzeitig macht das auch eine andere Instanz.
1 liest
2 liest
1 ändert und schreibt
2 ändert und schreibt

2 hat gewonnen

Hier müsste man über die gesamte Transaktion die betroffenen Tabellen oder Datensätze locken. 2 darf hier erst lesen, wenn 1 fertig ist.

Allerdings weiß ich jetzt nicht, ob das Locking bei MySQL auch entsprechend vorhanden ist - denke aber doch, weils ja sehr wichtig ist.

Gruß
Franz

[Blutgerinsel]

Hi
Probleme gibt es grundsätzlich dann, wenn jemand (ein script) etwas aus der DB liest, verändert und dann schreibt. Und gleichzeitig macht das auch eine andere Instanz.

Was bei wikipedia der Fall sein dürfte....

Ansonsten bleibt nur zu sagen das jede Verbindung zum MySQL Server einen eigenen Thread sprich Prozess zugeordnet bekommt....

Daneben bietet MySQL noch die Möglichkeit Inserts bei niedriger Last erst auszuführen mittels Insert Delayed....

[kellanved]

Allerdings weiß ich jetzt nicht, ob das Locking bei MySQL auch entsprechend vorhanden ist - denke aber doch, weils ja sehr wichtig ist.

Natürlich. MySQL setzt automatisch einen Lock wenn Tabellen verändert werden sollen. Daher auch die Möglichkeit auf "Delayed Inserts" auszuweichen.

Wie gesagt: es gibt durchaus Situationen, wo man noch zusätzlich manuell einen Lock setzen muss; aber in den "normalen" Fällen reicht MySQLs Mechanismus um solche Race Conditions zu vermeiden.

[Pyramide]

Probleme gibt es grundsätzlich dann, wenn jemand (ein script) etwas aus der DB liest, verändert und dann schreibt. Und gleichzeitig macht das auch eine andere Instanz.
1 liest
2 liest
1 ändert und schreibt
2 ändert und schreibt

Daher ist es z.B. auch sinnvoll, UPDATE tabelle SET feld=feld+1 zu verwenden anstatt erst zu lesen, dann in PHP zu erhöhen und wieder zu schreiben.

MyISAM Tabellen (das Standardformat) kennen übrigens keine Transaktionen über mehrere SQL Befehle.

[D@ve]

Hmmm man könnte sich mit PHP so ne Art Transaktions-Funktion nachbauen. An die übergibt man dann ein Array mit den ganzen Queries. Die Funktion extraiert dann automatisch die verwendeten Tabellen, setzt darauf ein LOCK, führt die Queries aus und gibt sie wieder frei. Allerdings wäre man hier auch darauf angewiesen, dass das komplette Script darauf optimiert ist.

Gruß, Dave

[Pyramide]

Bevor man sich solche Würgarounds programmiert sollte man lieber gleich richtige Transaktionen verwenden (z.B. mit dem Tabellentyp InnoDB). Der phpBB-DBAL bietet ja auch schon Unterstützung für Transaktionen ($db->sql_query("blah", BEGIN_TRANSACTION) und $db->sql_query("blub", END_TRANSACTION)). Allerdings habe ich noch keinen Code gefunden, der diese Möglichkeit auch tatsächlich nutzt.

[D@ve]

Bevor man sich solche Würgarounds programmiert sollte man lieber gleich richtige Transaktionen verwenden (z.B. mit dem Tabellentyp InnoDB). Der phpBB-DBAL bietet ja auch schon Unterstützung für Transaktionen ($db->sql_query("blah", BEGIN_TRANSACTION) und $db->sql_query("blub", END_TRANSACTION)). Allerdings habe ich noch keinen Code gefunden, der diese Möglichkeit auch tatsächlich nutzt.

Hab mir das mal angeschaut, die Funktion (in includes/mysql4.php)greift aber anscheinend auf MySQL-Kommandos zurück: BEGIN, COMMIT und ROLLBACK Das verstehe ich nicht ganz. MySQL4 gilt doch als DBMS ohne Transaktionen das habe ich schon mehrmals gelesen??

Für MySQL < 4 (includes/mysql.php) ist das anscheinend garnicht implementiert, da wird der Parameter einfach ignoriert.

Gruß, Dave