Mehrbenutzersysteme Datenbankzugriff

[Jack]

Hallo,

ich stehe vor dem Problem, dass ich eine MySQL Datenbank betreiben will, auf die Mehre Anwendungsprogramme gleichzeitig zugreifen. Nun kann es ja vorkommen, dass ein Benutzer die Daten in der DB ändert und ein anderer noch die alten Daten auf seinem Bildschirm stehen hat!

Wie umgehe oder löse ich dieses Problem am besten?

Vielen Dank!

 

[cham]

Also das ist ein geradezu klassisches Problem. Das wirst Du nur über einen Poll los oder falls ein zentraler Einsprungpunkt ein Änderung registriert und dann einen Broadcast an alles Clients sendet.

Das ganze ist aber nur theoretisch gedacht. Andere Ideen würden mich aber auch interessieren.

 

[ocb]

Sucht mal nach Concurrency Control und Transaktionsmanagement...dieses "klassische Problem" ist keins und wenn es eins wäre, gäbe es keine Datenbanksysteme.

Vereinfacht dargestellt läuft das ungefähr so:

Nehmen wir mal an, zwei Nutzer A und B sind an den gleichen Daten D interessiert.

1) A holt sich die Daten aus der Datenbank zum LESEN, er will sie also nicht verändern. Das DBMS versieht D mit einer Schreibsperre. B will jetzt auch D LESEN. Da nur eine Schreibsperre aktiv ist, kann der die Daten aus der Datenbank holen und sich angucken.

2) Selbe Ausgangssituation wie in 1), aber B will die Daten ändern. Das geht nicht, weil er für D keine "Schreiberlaubnis" bekommt (A hat die Daten ja noch und bevor er sie nicht wieder her gegeben hat, darf B nichts daran ändern).

Wie gesagt, das ist sehr vereinfacht dargestellt. Allgemein gilt: die Daten bleiben solange gesperrt, bis der Nutzer sie nicht mehr braucht. Gleichzeitiges Lesen ist erlaubt, gleichzeitiges Lesen/Ändern oder Ändern/Ändern dagegen nicht. Das Verfahren, welches in der Realität eingesetzt wird, ist wesentlich komplexer (Transaktionsmanagement, Pessimistic/Optimistic Locking, Intentional Locks/Exclusive Locks, Sperreskalation, ...).

 

[Thomas Darimont]

Hallo!

Je nach dem wie hoch das "Konkurrenz" Niveau auf deinem Datenbanksystem ist kommt wie ocb schon sagte entweder pessimistisches Locking (Datenbankseitige Sperre, der Tabelle, des Satzes oder der Spalte) oder optimistisches Locking ( "jeder" Datensatz wird mit einem Zähler ausgestattet der bei jeder Modifikation inkrementiert wird. Wenn ein Client nun einen Satz öffnet um zu schreiben liest er den Zählerstand aus und speichert ihn zwischen. Danach führt er die Geschäftslogik aus die den "neuen Wert" errechnet. Anschließend kommt es zum Schreibvorgang. Bevor jedoch die Veränderungen geschrieben werden wird wieder der Zähler ausgelesen und mit dem alten Wert verglichen. Hat sich der Wert geändert wurde der Satz zwischenzeitlich von einem anderen Benutzer verändert. Die Anwendung könnte in dem Fall eine Meldung hochbringen ("Modifikationswarnung"...). Hat sich der Zähler hingegen nicht geändert dann wurde der Satz zwischenzeitlich nicht manipuliert und kann gefahrlos geschrieben werden.

Gruß Tom

 

[cham]

Sucht mal nach Concurrency Control und Transaktionsmanagement...dieses "klassische Problem" ist keins und wenn es eins wäre, gäbe es keine Datenbanksysteme.

Das klassisch bezog sich auf die Forderung "einer ändert alle sehen sofort". Das hören wir bei Kunden jedes Mal aufs neue(auch bei Weblösungen). Eine praktikable Lösung haben wir bisher auch noch nicht gefunden.

 

[ocb]

Das klassisch bezog sich auf die Forderung "einer ändert alle sehen sofort". Das hören wir bei Kunden jedes Mal aufs neue(auch bei Weblösungen). Eine praktikable Lösung haben wir bisher auch noch nicht gefunden.

Das fällt in das Thema "Transaktionen". Arbeitet die Anwendung transaktionsbasiert, gibt es keine Probleme. Niemand kann Daten lesen, solange jemand daran ändert. Umgekehrt kann niemand Daten ändern, die noch zum Lesen von anderen angefordert sind (pessimistisches Sperrverfahren vorausgesetzt). Auch hier gilt: sehr stark vereinfacht dargestellt, praktische Verfahren sind komplexer. Ich sagte ja bereits: suche einfach mal nach Transaktionsmanagement oder einfach nach Transaktionen selbst.

 

[cham]

Gut war zwar nicht mein Thread und nun ist es fast schon ein bisschen OT aber trotzdem. Was Transaktionen sind und wie Transaktionen funktionieren ist mir bekannt. Schleisslich arbeite ich seit nunmehr 6 Jahren mit derlei Technologien.

Was ich aber bisher nicht gefunden habe und auch keine richtige Antwort gefunden habe(außer pollen), wie es möglich sein kann nach Transaktionen allen Clients die aktualisierten Informationen ohne deren Zutun ausliefern zu können. Ich habe die Fragestellung des Threaderöffners auch so interpretiert.

 

[Thomas Darimont]

Hallo!

Das man zu diesem Zweck eine Art Event Notification Mechanismus braucht ist klar, aber muss man den alles selber bauen...?
Liese sich so ein Verhalten nicht mittels JMS lösen?
Eigentlich könnte man doch die Publish Subscriber-Variante von JMS dazu verwenden das gewünschte zu realisieren. Alle Clients die über die Änderungen von bestimmten Ressourcen interessiert sind "subscriben" sich bei einem bestimmten Topic. Über diesen Weg werden alle Clients über eine Änderung an der jeweiligen Ressource informiert. Das wäre der "Rückkanal". Der "Kanal" welcher das Eigentliche "Änderungsereignis" an das Topic weitergibt ("Published") wird dann Serverseitig verwaltet. Sprich wenn in der Geschäftslogikschicht eine Änderung an einer zu überwachendem Ressource durchgeführt wird, wird eine Nachricht an das Topic geschickt über welches dann alle "registrierten" Clients benachrichtigt werden. Das ganze geht so natürlich nur, wenn die Geschäftslogik auf dem Server abläuft. Außerdem kann ich im Moment nicht sagen wie bzw. ob das ganze noch halbwegs gut skaliert... mal ausprobieren ;-)


Gruß Tom

 

[Jack]

Vielen Dank an Alle!

Das hat mir auf jeden Fall mal sehr geholfen!