Hallo T-Rex,
Deine Antwort ist - mit Verlaub - eine Unverschämtheit sondergleichen!
Meiner Ansicht nach ist das nicht relevant - [...]
Meiner Ansicht nach ist das nicht relevant - [...]
Meiner Ansicht nach ist das nicht relevant - [...]
Meiner Ansicht nach ist das nicht relevant - [---]
Was soll wie ablaufen? Transaction starten und mittels commit abschliessen. Gibt es da so viele unterschiedliche verfahren?
Nun meine Fragen:
Welches DBMS
MySQL 5.irgendwas.
Aha!
Wie findet der Zugriff statt? -> Protokoll!
http
Aha!
Und finden die gesamten Datenbankaktionen innerhalb eines einzigen Requests statt?
Welche weiteren Randbedingungen müssen beachtet werden?
Keine Ahnung?
Schon scheiße! Darüber verschafft man sich üblicherweise zuerst einen Überblick
* mehrere gleichzeitige User auf der Datenbank?
Nein
Achso, Du übst nur und willst niemals einne Produktivzustand erreichen?
* hoher Datenbank-Traffic?
Das Spielt denke ich keine Rolle,
Du hast doch gefragt, um herauszufinden, was Andere denken. Warum also jetzt diese Aussage?
da selbst 2 Verarbeitungen im Monat sich in die Quere kommen könnten.
Aha! Die Verbindung zur Datenbank fpe den einen Request / die eine Requestgruppe (an die Datenbank) bleibt also ggf. mehrere Monate aktiv?
Die Chancen sind zwar nicht besonders groß aber theoretisch möglich.
Chancen sind immer möglich - darum sind es Chancen.
Ich übersetze jetzt mal: Konflikte sind möglich.
Wie hoch die Wahrscheinlichkeit für Konflikte ist generell egal, wenn man sie vermeiden kann!
* viele Veränderungen pro Zeiteinheit?
Meiner Ansicht nach ist das nicht relevant - aber wenn es dir hilft aktuell so gut wie gar nichts.
Aha!
Transaktionen sind üblicherweise nur in zustandsorientierten Systemen bei verbindungsorientierten Protokollen sinnvoll- Liegen diese Voraussetzungen bei Dir vor, oder erstrecken sich die Aktionen vielleicht über mehrere Roundturns einer HTTP/s-Sitzung?
Also meine Frage ist natürlich durch ein aktuelles Projekt / Problem geboren. Dennoch hoffe ich dass man eine generelle Antwort treffen kann. Was ich nicht möchte ist, dass bei script a.php eine transaktion gestartet wird und bei b.php wird sie beendet. Es spielt sich alles innerhalb eines Scriptaufrufes ab. Um genau zu sein werden zwei aufeinander aufbauende Datensätze erstellt. Da der eine ohne den anderen nicht sinnvoll ist wollte ich um das Ganze Speichern eine Transaktion bauen und sie nur commiten wenn beide Speichervorgänge erfolgreich sind. Da der eine Datensatz die Id des anderen beinhaltet frage ich doch mal lieber wie sicher die Id ist. Eventuell ändert sich die Id ja, nach dem commit. Dann wäre die Referenz zerstört.
Also Transaktion innerhalb eines Requests an die API, der dann die x Requests an die DB auslösen soll?
Da kann man viele Probleme schon beim Design des Datenmodells - strikte Trennung von Stammdaten und Bewegungsdaten - vermeiden. Und wenn denn keine anderen Requests gleichzeitig zu erwarten sind, kann man sich die Transaktion normalerweise schenken. Da reicht es, die betroffenen Tabellen _vorher_ gegen andere Zugriffe zu sperren.
Mit lieblich säuselndem Antwortgruß
RdG