  |
  |
| Home Überblick Suche Impressum Kontakt Mitglieder | |||||||||||||||||||||||
Bisher konnten konkurrierende Schreibzugriffe entweder über die System-Semaphore cgi synchronisiert werden, oder es lag in der Verantwortung des Entwicklers, bei jedem Schreibzugriff eine Semaphore einzurichten - Besonders bei Entwicklung im Team fehlerträchtig. Der locking daemon ermöglicht es nun, diese Synchronisation an zentraler Stelle automatisch durchzuführen. Beim Start baut die tdbengine eine TCP/IP-Verbindung zu dem im Hintergrund laufenden locking daemon auf. Bei jeder Aktion, die eine Synchronisation erfordert (s.u.), kommuniziert die tdbengine über diese Verbindung mit dem locking daemon und fordert Sperren an oder gibt diese frei. Dies kann man in der Logdatei beobachten. Installation Für die Verwendung des locking daemons ist das Programm tdb_lockd sowie die dazu gehörige tdbengine erforderlich. Diese ist an einem an die Versionsnummer angehängten -net erkennbar und bisher nur für Linux erhältlich. Der daemon muß, wie der Name schon andeutet, als Hintergrundprozess auf der Konsole gestartet werden. Hierzu geben Sie auf der Linux-Konsole folgenden Befehl ein: nohup ./tdb_lockd > tdb_lockd.log Danach kann die Konsole geschlossen werden, der daemon läuft im Hintergrund weiter. Es wird eine Datei tdb_lockd.ini angelegt, in der die Verwaltungsinformationen abgelegt werden. Die log-Datei kann man mit tail -f tdb_lockd.log mitlaufen lassen. Beendet wird der daemon mit killall tdb_lockd Verwendung Für das locking sind die neu aktivierten alten Befehle Lock, Unlock, EditOn, EditOff, GetSession, DelSession, GetSessionIdent und SetSessionIdent zuständig. Tabellen-Sperren Wenn eine Tabelle unter Verwendung des locking daemons geöffnet wird gilt: Zu einem Zeitpunkt können entweder genau ein schreibender oder beliebig viele lesende Zugriffe auf eine Tabelle erfolgen. Die Beschränkung auf genau einen schreibenden Zugriff bedarf der Erläuterung. Sie hängt in erster Linie mit der Indizierung einer Tabelle zusammen. Es wäre schließlich denkbar, dass der Anwender A den Datensatz X und der Anwender B den Datensatz Y ohne weitere Komplikationen gleichzeitig verändern können. Für die Tabelle selbst ist dies auch richtig. Eine einzige Änderung einer Indexinformation hingegen kann zu einer völligen Umstrukturierung der gesamten Indexdatei führen. Deshalb dürfen während der Aktualisierung der Indexe keine weiteren schreibenden Operationen in der Tabelle stattfinden. Bezüglich der Indizierung ist demnach jeder schreibende Zugriff eine die gesamte Tabelle betreffende Operation. Der locking daemon unterscheidet nicht zwischen indizierten und nichtindizierten Tabellen, obwohl letztere in der Praxis kaum vorkommen. Um gleich hier einem möglichen Mißverständnis vorzubeugen: Die obige Regel gilt natürlich nur für den eigentlichen Übertragungsvorgang von Informationen (also Datensätzen) vom Rechner auf das externe Speichermedium. Die Dateneingabe selbst, also das Ausfüllen von Formularen ist davon selbstverständlich nicht betroffen. Es können beliebig viele Anwender gleichzeitig Daten in Formulare eingeben. Erst wenn die Eingabe eines Satzes abgeschlossen ist und der Satz "geschrieben" werden muss, tritt die Regel in Kraft. Damit die Regel immer eingehalten wird, setzt der locking daemon bei lesenden und schreibenden Zugriffen auf eine Tabelle sogenannte Sperren ein. Bei einem schreibenden Zugriff ist die Sperre total (Totalsperre), es werden also während dieser Zeit überhaupt keine anderen Zugriffe auf die Tabelle zugelassen. Beim lesenden Zugriff hingegen wird die Datei nur für schreibende Zugriffe anderer Anwender gesperrt (Schreibsperre). Satz-SperrenWenn Tabellen von Anwendern interaktiv bearbeitet werden sollen gilt: Befindet sich ein Datensatz bei einem Anwender in Bearbeitung, so darf dieser Datensatz von einem anderen Anwender nicht gleichzeitig bearbeitet oder gelöscht werden. Während der Bearbeitung durch den Anwender sollte also nicht die gesamte Tabelle gesperrt, sondern nur derjenige Datensatz, der davon betroffen ist (Satz-Sperre). Diese Sperre betrifft auch nicht alle Operationen auf diesem Datensatz (z.B. kann er nach wie vor gelesen werden), sondern nur das Editieren oder Löschen dieses Satzes durch einen weiteren Anwender. Zur Einhaltung muß das Programm entsprechende Sperren einrichten. Für die Sperren gilt folgende Grundregel: Hier eine Aufstellung aller Tabellen-Funktionen, die automatische Sperren einrichten:
|
|
||||
|
 tdbengine chat irc.tdbengine.org #tdbengine |
|
| |
Copyright © 2003-2004 tdb Software Service GmbHAlle rechte vorbehalten. / All rights reserved Letzte Änderung: 02.10.2008 |
|
|
|
||
| |||