<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#FFFFFF">
Roland Henkel schrieb:
<blockquote TYPE=CITE><style></style>
<font face="Arial"><font size=-1>Liebe
Liste,</font></font> >Die Frage ist m.E., wann presto das Signal bekommt,
daß der Satz geschrieben
<br>>und die Datei geschlossen ist. Mag sein, daß der entsprechende
Systemaufruf
<br>>die Steuerung zurück gibt, wenn er die Anforderung in die entsprechende
<br>>Anforderungswarteschlange eingestellt hat. Presto aber setzt inzwischen
dann
<br>>schon das Bit in der TBL-Datei zurück, so daß ein neuer
Client die DB als
<br>>zugänglich vorfindet. während die reale Aktion noch Schlange
steht.
<br> <font face="Arial"><font size=-1>es ist mir aufgefallen,
daß diese "Hypothese" einen Denkfehler enthält. Die</font></font><font face="Arial"><font size=-1>Schreibanforderung
des neuen Clienten, die diesem auf Grund des schon zurückgesetzten</font></font><font face="Arial"><font size=-1>TBL-Bits
gesattet wird, würde ja ebenfalls in die Warteschlange eingeordent
werden,</font></font><font face="Arial"><font size=-1>womit dann doch eine
gewisse Synchronität gewährleistet ist.</font></font> <font face="Arial"><font size=-1>Allerdings
bliebe bestehen, daß das Schreiben der Sätze letzendlich unabhängig</font></font><font face="Arial"><font size=-1>vom
gesetzen oder nicht gesetzten TBL-Bit erfolgt. Dieses steuert lediglich,
ob eine</font></font><font face="Arial"><font size=-1>Schreibanforderung
überhaupt erlaubt wird.</font></font> <font face="Arial"><font size=-1>Ich
denke, daß ist zwangsläufig der Fall, wenn die Synchronisierung
vom Nutzer- bzw. Clientprogramm</font></font><font face="Arial"><font size=-1>und
nicht durch Semaphore oder wait und post Mechanismen des Systems</font></font><font face="Arial"><font size=-1>vorgenommen
werden.</font></font></blockquote>
<p><br>Hallo Liste, Liebe Entwicklungsabteilung,
<br>ich denke, Herr Henkel trifft das Problem-Umfeld genau. Da ich leider
nicht genau weiß
<br>wie die Reihenfolge beim Allegro-DB-Zugriff definiert ist, schreibe
ich mal auf,
<br>wie nach meiner Meinung ein Schreibzugriff (z.B. Datensatz ändern)
ablaufen müßte
<br>und bitte die Entwicklungsabteilung, mir zu sagen, ob ich da richtig
liege:
<p>(Leser ohne Programmierkenntnisse: bitte wegen der verkürzten Schreibweise
<br>nicht böse sein)
<p>Szenarium: vorhandener Satz wird vom Client-System (Nutzer) editiert
und
<br>zurückgespeichert; Satz ist größer als vorher und muss
umgespeichert werden:
<p>A -------------------------------------------------------
<br>Nutzer:
<br>- Satz zum Editieren öffnen (z.B. presto "E")
<br>System:
<br>- .TBL lock
<br>- neu einlesen
<br>- wenn Satz frei, Sperrkennzeichen setzen
<br>- .TBL unlock
<p>B --------------------------------------------------------
<br>Nutzer:
<br>- Editieren abbrechen
<br>System:
<br>- .TBL lock,
<br>- Satzsperre zurücksetzen
<br>- .TBL unlock
<p>C --------------------------------------------------------
<br>Nutzer:
<br>- geänderten Satz speichern
<br>System:
<br>1 - alle beteiligten Dateien lock (atomar: .xDX, .TBL, .xLD, evtl ..STL)
<br>wenn erfolgreich:
<br>2 - aktuellen Zustand der zu verändernden Dateien neu einlesen:
.xDX, .xLD .TBL, .STL
<br>3 - beteiligte Dateien aktualisieren
<br>4 - alle beteiligten Dateien unlock (atomar)
<p>Bei ALF verschärft sich das Ganze noch, denn dann müßte
das Lesen und
<br>Aktualisieren MEHRERER Datensätze in eine Transaktion (C 1-4)
eingeschlossen
<br>sein.
<p>Die beschriebenen Effekte können m.E. entstehen, wenn sich Operationen
in
<br>verschiedenen Dateien, von mehreren Clients ausgelöst, im Netz
überholen.
<br>Das Netz-Betriebssystem stellt zwar sicher, dass für EINE Datei
die zeitl.
<br>Reihenfolge der verschiedenen Client-Anforderungen eingehalten wird,
aber
<br>nicht zwischen VERSCHIEDENEN Dateien. Von Zusammenhängen zwischen
<br>verschiedenen Dateien weiß das System nichts.
<p>mfg. Anando Eger
<br>
<br>
<br>
</body>
</html>