Massiver Mehrnutzerbetrieb - Strategie

05/01/2009 - 15:22 von Christoph Dreßler | Report spam
Hallo.

Gesundes Neues Jahr erstmal!

Ich muss etwas ausholen, damit die Problematk verstàndlich ist.

Gegeben:
- VFP9-App, ca. 200 gut gefüllte Tabellen (10-100 MB / Tabelle)
- DBFs über DBC/SQL-Views verbunden.

Szenario A:
20 gleichzeitige Nutzer, die machmal parallel eine Form öffnen, die ca
30 Tabellen öffnet.
Problem:
In seltenen, aber àrgerlichen Situationen kommt es zu
Zugriffskonflikten wie:
"Datenbank wird bereits benutzt" oder "Tabelle wird von anderen
Benutzer..."
Ursache ist, dass Befehle, die Dateiheader kurz öffnen, wie
TABLEUPDATE(), USE <view>, SQL-SELECT
wohl sehr kurz einen Exclusivzugriff brauchen.
Try-Catch-Kapselung geht nicht, weil auch impliziete Stellen wie
AutoOpen der Form-Datenumgebung dabei sind.

Szenario B:
Eine Funktion, die eine "Transaktion" ist, z.B. das Rückschreiben von
20 Tabellen.
Problem:
Diese muss aus Integritàtsgründen exclusiv laufen.

Meine aktuelle Lösung:
Manuelle Transaktionkontrolle in der Form, dass ich eine
Low-Level-Datei zum Schreiben öffne, und nach erfolgreicher Operation

wieder schließe.

Vorteil:
1. Andere Nutzer können diese nicht parallel öffnen
2. Ich kann eine zivile Meldung mit dem sperrenden Client usw. bringen
3. Low-Level ist vom System(OS, Virenscanner, Netzwerk) gute
handhabbar. Ein Blick auf FILEMON verdeutlicht das.
Ein Versuch mit DBF und RLOCK führte seinserseits zu
Zugrifsskonflikten.

Nachteil:
- Das Schreibhandle wird im Störungsfall nicht zuverlàssig
freigegeben, z.B. wenn die LAN-Verbindung zum Client verlorengeht.
Das manuelle Freigeben führt zu rel. hohem Supportaufwand und Frust
bei den Nutzern.

Eine Nur-Lesen-Datei möchte ich nicht, weil ich fürchte, dass das dann
nötige Neueinlesen von Pufferproblemen gestört wird.
Habs aber nicht im Feldversuch getestet.

Ein Zeitstempel-Verfahren beherrsche ich kaum, weil nicht alle
Cliensts die selbe Zeit haben und ich das auch nicht erzwingen
will/kann. Außerdem wiederum evtl. Pufferungsproblme.

Weiteres Ziel ist, den "Warten auf anderen Nutzer..."-Zustand oder gar
Dead-Locks auszuschließen.

Nun meine Frage: Mit was für Verfahren handhabt ihr den massiven
Mehrnutzerzugriff bzw. Transaktionen?
Mir reichen Ideen-Skizzen.


Vielen Dank für Tipps!

-christoph
 

Lesen sie die antworten

#1 Axel Netzband
05/01/2009 - 17:17 | Warnen spam
Christoph Dreßler schrieb:

Hallo.

Gesundes Neues Jahr erstmal!

Ich muss etwas ausholen, damit die Problematk verstàndlich ist.

Gegeben:
- VFP9-App, ca. 200 gut gefüllte Tabellen (10-100 MB / Tabelle)
- DBFs über DBC/SQL-Views verbunden.

Szenario A:
20 gleichzeitige Nutzer, die machmal parallel eine Form öffnen, die ca
30 Tabellen öffnet.
Problem:
In seltenen, aber àrgerlichen Situationen kommt es zu
Zugriffskonflikten wie:
"Datenbank wird bereits benutzt" oder "Tabelle wird von anderen
Benutzer..."
Ursache ist, dass Befehle, die Dateiheader kurz öffnen, wie
TABLEUPDATE(), USE <view>, SQL-SELECT
wohl sehr kurz einen Exclusivzugriff brauchen.
Try-Catch-Kapselung geht nicht, weil auch impliziete Stellen wie
AutoOpen der Form-Datenumgebung dabei sind.

Szenario B:
Eine Funktion, die eine "Transaktion" ist, z.B. das Rückschreiben von
20 Tabellen.
Problem:
Diese muss aus Integritàtsgründen exclusiv laufen.

Meine aktuelle Lösung:
Manuelle Transaktionkontrolle in der Form, dass ich eine
Low-Level-Datei zum Schreiben öffne, und nach erfolgreicher Operation

wieder schließe.

Vorteil:
1. Andere Nutzer können diese nicht parallel öffnen
2. Ich kann eine zivile Meldung mit dem sperrenden Client usw. bringen
3. Low-Level ist vom System(OS, Virenscanner, Netzwerk) gute
handhabbar. Ein Blick auf FILEMON verdeutlicht das.
Ein Versuch mit DBF und RLOCK führte seinserseits zu
Zugrifsskonflikten.

Nachteil:
- Das Schreibhandle wird im Störungsfall nicht zuverlàssig
freigegeben, z.B. wenn die LAN-Verbindung zum Client verlorengeht.
Das manuelle Freigeben führt zu rel. hohem Supportaufwand und Frust
bei den Nutzern.

Eine Nur-Lesen-Datei möchte ich nicht, weil ich fürchte, dass das dann
nötige Neueinlesen von Pufferproblemen gestört wird.
Habs aber nicht im Feldversuch getestet.

Ein Zeitstempel-Verfahren beherrsche ich kaum, weil nicht alle
Cliensts die selbe Zeit haben und ich das auch nicht erzwingen
will/kann. Außerdem wiederum evtl. Pufferungsproblme.

Weiteres Ziel ist, den "Warten auf anderen Nutzer..."-Zustand oder gar
Dead-Locks auszuschließen.

Nun meine Frage: Mit was für Verfahren handhabt ihr den massiven
Mehrnutzerzugriff bzw. Transaktionen?
Mir reichen Ideen-Skizzen.


Vielen Dank für Tipps!

-christoph



hallo christoph (und gesundes neues jahr)

also strategisch gesehen würd ich in richtung SQL-Server schauen !!!
(MySQL, etc.) - die dinger setzen nàmlich u.a. genau an diesem punkt an
und verwalten client-datenzugriffe zentral.

gruß aus kassel
axel

Ähnliche fragen