Single-User auf Multi-User umstellen

[Magoo]

Hallo Leute!

Ich möchte mal gerne eure Meinung über mein bevorstehendes Problem hören:

Wie würdet ihr ein Single-User-Programm auf ein Multi-User-Programm umstellen?

Das Programm greift bereits jetzt auf eine Oracle-Datenbank zu, die auf einem Anderen System läuft. Es gibt also schon einen gewissen Client-Server-Zugriff. Jedoch wird nicht abgefangen, ob ein Datensatz von zwei Clients gleichzeitig bearbeitet wird.

Wie würdet ihr diese Abfrage machen, um zu verhindern, das zwei Clients gleichzeitig einen Datensatz bearbeiten?

So. Das sollte reichen. Fall ihr Rückfragen haben solltet, werde ich versuchen diese zu beantworten.

Bin dann jetzt mal gespannt, wie ihr das lösen würden.

Bis dahin...

CU

Magoo

[haddock]

Ich denke da sollte es kein Problem geben, da Oracle selber schon Zugriffschutz bietet. Je nachdem, wie der Zugriff aussieht - lesend oder schreibend - ist ja auch kein Schutz notwendig. Aber Oracle wird bestimmt dafür sorgen, daß keine zwei user gleichzeitig denselben Datensatz bearbeiten können, dafür gibt es locks auf Zeilen- und Tabellenebene und darüber hinaus eine Transaktionsverwaltung.

Ist das eine Produktionsdatenbank oder habt ihr auch ein Testsystem, in letztem Fall würde ich einfach mal versuchen, den GAU auszulösen. Nach dem, was ich über Oracle gelernt habe, sollte dir das nicht gelingen

<FONT COLOR="#a62a2a" SIZE="1">[ 19. Oktober 2001 08:43: Beitrag 1 mal editiert, zuletzt von captain haddock ]</font>

[Crush]

Also ich bin mir da nicht ganz so sicher, weil ich´s nicht getestet hatte aber wahrscheinlich stimmt das schon...

ich habe als Abschlußprüfung einen Oracle-Client (gedacht als ODBC-Alternative-Class für ein Produkt) erstellt. Mein "Chef"-Programmierer war oraclemäßig wirklich topfit und ich habe auch das ganze (ohne irgendwelche Zusatzanmeldungen zum Sperren oder ähnliches) für Multiuser (nicht direkt nur fürs Netz, sondern für mehrere User am selben Rechner, also mehrere mal kann das Programm parallel gestartet werden) erstellt - ich kam wegen dem Prüfungsstreß nicht mehr dazu das ganze tatsächlich ins Hauptprogramm zu implementieren, aber da das ein wichtiger Bestandteil der Klasse war und ich vor der Prüfung alles auf Funktionsfähigkeit allein im Debugger mit nem kleinem Testprogramm und mit dem Oracle-Mann logisch betrachtet durchging und der in keinster Weise diesem Multi-Instanz-Verfahren ohne DB-Sperrung oder ähnliches voll zustimmte gehe ich davon aus, daß das schon geht - man bekommt halt wohl eine Fehlermeldung, sollte ein Datensatz bearbeitet werden - auf jeden Fall beim Schreiben. Schlimmstenfalls würde sich Oracle die Vorgänge merken und nach der Reihenfolge der Anmeldung abarbeiten, das wäre auch noch korrekt.

Leider ist nachher nix mehr draus geworden, weil man sich nach 2 Tagen harter Arbeit dafür entschied das ganze wegen der Beschleunigungs- und Optimiermöglichkeiten über OCI laufen zu lassen, also mußte ich alles nochmal von vorne schreiben, weil OCI komplett anders funktioniert (aber abgesehen davon die höchste Aktualisierung seitens Oracle hat) aber auch unvergleichlich schwieriger zu realisieren ist (um ehrlich zu sein nach der 1500-Seiten-Anleitung für die Programmierschnittstelle stand ich erst mal da wie der Ochs vorm Berg). Also rein von der Benutzung ist das wie das Steinrad vom Neandertaler (Oracle-ODBC & T-Net) im Vergleich zum Ferrari (OCI).

Wenn Du mal jemand so richtig leiden lassen willst, oder mal testen willst, was DB-Programmierung noch so bedeuten kann, dann zieh Dir mal von der Oracle Developer-Page die OCI-Anleitung, vor allem deshalb, weil sich mit OCI praktisch kaum einer auskennt und nur wenig brauchbare Dokus existieren, aber Dich im DB-Bereich OCI-Kenntnisse zum Guru erleuchten. OCI ist übrigens ein Standard, der von fast allen Datenbanken (auf jeden Fall denen die was taugen) unterstützt wird.

Aber um nochmal auf die Frage zurückzukommen:

Eine gesonderte Behandlung auf parallele Transaktionen würde ich nur dann beim Server direkt nochmal implantieren, wenn es absolut unerläßlich ist herauszufinden, wer wann an der Datenbank rumgespielt hat. Das könnte man bestimmt auch in den Server-Logs irgendwie rausbekommen können, aber sollte das in einem extra Server-Programm benötigt werden, dann mußt Du halt die Abfragen nach gleichen Tabellen checken bevor sie an die Datenbank geschickt werden und diese gegebenenfalls direkt blockieren oder halt in eine "Warteschlange" setzen. Das würde aber bedeuten, daß die Kommunikation zu Datenbank auf ein Extraprogramm umgelenkt werden muß, welches halt für die Clients vor sich hinrödelt - und das wäre auch ein (relativ) enormer Aufwand für ein bestehendes Client-Programm und unnötiger Traffic würde verursacht. Ob das wirklich notwendig ist??? Was nicht unbedingt sein muß muß auch nicht programmiert werden, weil die Kunden nur dafür zahlen, was sie wirklich wollen und nicht für den 5. Airbag oder eine zusätzliche Kühlerskülptur aufkommen wollen.

Immer im voruas schon Input-Output abwägen und nur dann Input zulassen, wenn der Output dafür auch garantiert ist!

Im schlimmsten Fall muß man sich halt überlegen, ob die Clients voneinander wissen dürfen und die Sperrung selber miteinander ausmachen. Also ich würde das alles einfach der Datenbank überlassen - die kümmert sich schon drum (hat ja auch genug gekostet) und ein GAU ist nicht zu erwarten.

Die Frage ist halt auch, wie das Programm auf eine Sperrung reagiert. Sollte da dann einfach eine Fehlermeldung kommen, ein Retry, oder halt erstmal gar nix? Da würde ich mir eher drüber Gedanken machen. Und es ist auch die Frage wann das bemerkbar wird: Beim Select oder erst beim Schreiben? Hier würde ich erstmal rumtesten und dann weitere Schritte überlegen.

<FONT COLOR="#a62a2a" SIZE="1">[ 19. Oktober 2001 10:00: Beitrag 3 mal editiert, zuletzt von Crush ]</font>