Deutsch English
Blog
Home
Über tdbengine
Newsletter
Download
Helpware
Chat
Dokumentation
Installation
Konfiguration
Erste Schritte
Variablentypen
Laufzeitschalter
Textdateien
Systemfunktionen
Tabellenfunktionen
Indexfunktionen
Volltext-Indizierung
Memos und Blobs
Semaphoren-Konzept
Fehlermeldungen
Tipps für PHP Programmierer
Locking daemon
Einführungskurs
Befehlsreferenz
HOWTO - Wie kann ich...?
Projekte
Links
Benchmarks
Bug Reporting
Supportanfrage
 
Home    Überblick    Suche    Impressum    Kontakt    Mitglieder

Locking daemon

Beschreibung
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-Sperren
Wenn 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:
Schreibende Zugriffe führen zu Totalsperren, lesende Zugriffe führen zu Schreibsperren.
Damit die gemeinsame Arbeit mehrerer Anwender mit einer Tabelle nicht durch übertrieben lange Pausen behindert wird, sollten sämtliche Sperren nur so lange wie unbedingt nötig aufrecht gehalten werden.

Automatische Sperren
Hier eine Aufstellung aller Tabellen-Funktionen, die automatische Sperren einrichten: 

Funktion Sperren
ReadRec Schreibsperre
WriteRec Totalsperre, Satzsperre (wenn x<=FileSize)
DelRec Satzsperre, Totalsperre
FindRec Schreibsperre
GenInd Totalsperre
LinkBlob Totalsperre, Blobsperre
ReadMemo Totalsperre, Memosperre
CopyMemo Schreibsperre, Memosperre



tdbengine Anwendungen im Web:

Open-Source Web CMS


Open-Source Bug-Tracking


Free wiki hosting

Open-Source Wiki-System

Kostenloses Foren-Hosting

Diät mit tdbengine 8-)

tdbengine chat
irc.tdbengine.org
#tdbengine

   Copyright © 2003-2004 tdb Software Service GmbH
   Alle rechte vorbehalten. / All rights reserved
   Letzte Änderung: 02.10.2008
{Fehler für :execmacro{execmacro="sessionspy"}


ranking-charts.de

Programmers Heaven - Where programmers go!