Sponsored Links |
|
||||
chorn hat es ganz gut skizziert. Ich würde auf keinen Fall schon beim Aufruf irgendwas locken, damit blockiert man das System oder zumindest Teile, das halte ich für eine schlechte Lösung, auch wenn es einfacher zu realisieren ist.
Die Transaktion muss auch nicht über den gesamten Verlauf erfolgen, der Abruf am Anfang hat ja nicht zwangsweise auch einen Schreibvorgang zur Folge. Es reicht beim Speichern zu prüfen, ob es in der Zwischenzeit Änderungen gab, wenn nein dann commit, wenn ja dann rollback. Wer zuletzt speichern will hat halt pech und muss seine Änderungen kontrollieren/überarbeiten, genau wie bei der Versionsverwaltung. |
Sponsored Links |
|
||||
Argh, bitte klärt mich auf, ich sehe immer noch keine Notwendigkeit für Transaktionen, geschweige denn ein Szenario, wo Transaktionen helfen könnten diese Probleme zu beheben.
Ich komme mir so vor, als ob ich gar nichts mehr sehen können dürfte, so groß wie das Brett vor meinem Kopf sein muss. Ich meine, wenn es darum geht, dass eine Bearbeitung eine Aktualisierung von mehreren Datensätzen zur Folge hat, dann ist das klar, aber wenn ich nur einen Datensatz in einer Tabelle habe, dann ist doch ein simples UPDATE-Query genauso atomar, wie eine Transaktion, oder nicht? Ich meine, wenn zwei UPDATEs für den gleichen Datensatz reinkommen, dann hat erstmal das zweite UPDATE gewonnen, aber wenn ich z.B. "WHERE `lastModified` = 'XXXX'" (was auch immer der alte timestamp war) in die Bedingung aufnehme, dann ist die zweite Änderung nicht mehr erfolgreich und man kann entsprechend darauf reagieren. Oder geht es hier darum, dass man innerhalb einer Transaktion den Datensatz zunächst per (z.B.) SELECT ... FOR UPDATE abfragen und locken kann, um dann sicher sein zu können, dass der Datensatz seit diesem Lesevorgang und dem dann folgendem Update nicht mehr geändert werden kann? |
|
||||
Zitat:
|
|
||||
Zitat:
Ist das so? Ich dachte, dass die Datensätze, die selektiert werden, explizit für das folgende UPDATE gelockt werden müssten. Wenn das nicht so ist, dann geht das natürlich so. Danke, dann kann ich das Brett nun endlich abnehmen. |
|
|||
Da ich mich auch den halben Thread über gefragt habe, was Transaktionen bringen sollen:
Der einzige Zweck der Transaktion besteht darin, dass ich beim Abspeichern des Datensatzes sicherstellen kann, dass zwischen dem Prüfungsvorgangs („Es wurde nichts verändert, während ich den Datensatz bearbeitet habe“) und dem tatsächlichen Aktualisieren des Datensatzes keine Änderung am Datensatz erfolgen kann. Passt das so? |
|
||||
Jop, so hab' ich das jetzt auch verstanden.
Was aber halt nur Fall 2 von den ursprünglichen Fällen abdeckt. Um Fall 1 muss man sich trotzdem selbst kümmern, z.B. indem das Datum der letzten Änderung beim Auslesen für das Formular zwischengespeichert und beim Save-Request mit übergeben wird. Sonst hat man da ja überhaupt keinen Anhaltspunkt, um festzustellen, ob der Datensatz in der Zwischenzeit geändert wurde. Das war mein eigentliches Verständnisproblem, ich dachte erst, dass inta meinte, dass man diesen Schritt durch Transaktionen vermeiden könnte, was sich mir aber überhaupt nicht erschließen wollte. |
|
||||
Ja, das trifft es ganz gut. Ich finde das ist ein sehr wichtiger Grund für Transaktionen, da sie helfen den Datenbestand konsistent zu halten. Ich halte Locks für weitaus problematischer, vor allem wenn sie über einen längeren Zeitraum aktiv bleiben.
|
|
|||
Zitat:
Zitat:
PHP-Code:
Zitat:
|
Sponsored Links |
|
|||
Bin da jetzt mit Ajax noch nicht so ganz auf dem Laufenden, aber wäre es nicht auch denkbar mit Ajax alle x Min die Datenbank abzufragen und dem Kaffeetrinker dann eine nette kleine Mitteilung anzuzeigen, dass sich da was geändert hat?
|
Sponsored Links |
Themen-Optionen | |
Ansicht | |
|
|
Ähnliche Themen | ||||
Thema | Autor | Forum | Antworten | Letzter Beitrag |
Problem mit Text neben Navigationsleiste | andi01 | CSS | 6 | 08.06.2011 17:54 |
HTML mit PHP Code aus Datenbank auslesen + ausführen | Garlandt | Serveradministration und serverseitige Scripte | 14 | 01.05.2011 13:45 |
Mitwachsender Content und Footer Problem | Bentham | CSS | 5 | 19.09.2010 12:49 |
IE 7: Zoom Problem, Höhen Problem, Text problem | Cu Chullain | CSS | 4 | 02.09.2010 14:56 |
Problem mit Background-Color im FireFox | to.ni | CSS | 2 | 31.08.2004 12:13 |