1              Themenübersicht

Die Sperrverwaltung hat in Semiramis die folgenden Funktionen:

• Datenzugriff: Koordination des Zugriffs auf die gemeinsamen Daten (im Wesentlichen auf Business Objects).
• Klassenaustausch: Austausch von Java-Klassen zur Laufzeit.
• Schemamodifikation: Modifikation des Datenbankschemas zur Laufzeit.

Sie erfahren unter anderem, welche Sperr-Typen und Sperr-Arten verwendet werden und wie die Cache-Synchronisation realisiert wurde.

2              Zielgruppe

• Systemadministratoren
• Entwickler

3              Voraussetzungen

Folgende Kenntnisse werden vorausgesetzt:

• Programmierung
• Semiramis-Architektur

4              Begriffsbestimmungen

Application Code Class Loader

Ein Application Code Class Loader ist ein spezialisierter Class Loader, um Anwendungslogikklassen zu laden. Jeder Application Code Class Loader greift auf eine in sich konsistente Menge von Javaklassen zu und gehört zu genau einer Session. Application Code Class Loader laden nur Anwendungslogikklassen. Unterschiedliche Sessions können unterschiedliche Application Code Class Loader besitzen. Die Instanzen von Klassen, die mit unterschiedlichen Class Loadern geladenen wurden, sind nicht kompatibel. Aus diesem Grund lädt ein Application Code Class Loader keine sessionübergreifend benutzten Klassen, wie Parts und Business Objects beziehungsweise Systemklassen.

Clients

In der Client-Server-Kommunikation wird in diesem Dokument der Client mit einem Semiramis Application Server (SAS) gleichgesetzt. Der Server ist hier der Message Server (ausgezeichneter SAS)

Ressource

Als Ressourcen werden verstanden:

• Java-Klassen

Anwendungen, Logik-Klassen, Business Objects, Parts

• Business-Object-Instanzen

Alle Instanzen eines Business Object in einer Datenbank, eine Gruppe von Instanzen sowie eine einzelne spezielle Instanz.

Shared Cache

Der Shared Cache dient der Zwischenspeicherung von bereits geladenen Business-Object-Instanzen im Hauptspeicher, um Datenbankzugriffe zu vermeiden. Er ist damit ein wichtiger Bestandteil, der zur Leistungsfähigkeit von Semiramis beiträgt.

Lesende Zugriffe auf die Datenbank laufen generell über den Shared Cache. Bei dem Laden eines Business Object wird dieses zunächst im Transaction Cache, dann im Shared Cache und zuletzt in der Datenbank gesucht.

Sperre

In einem Mehrbenutzer-System besteht die Notwendigkeit, die Nutzung gemeinsamer Ressourcen zu regeln. Dazu wird eine Sperre (Lock) verwendet. Eine Sperre dient der Synchronisation von Zugriffen auf beschränkte Ressourcen.

Subkey

Ein Subkey ist ein Teil eines mehrteiligen Primärschlüssels. Der mehrteilige Primärschlüssel besteht aus einer groben und einer oder mehrerer feineren Ebenen. Ein Subkey beginnt stets mit der gröbere Ebene und umfasst danach die feineren Ebenen.

5              Sperre anfordern

Eine Sperre wird für eine Ressource in einem bestimmten Kontext angefordert. Die Kontexte in denen Sperren angefordert werden können sind diese:

• Activation Group

Eine Activation Group fasst eine Gruppe von Jobs zusammen, die eine gemeinsame in sich konsistente Menge von Java-Klassen (vergleichbar Build/Version/Release) benutzen.

• Job

Ein Job entspricht einer Session in Semiramis.

• Transaction

Der Transaktions-Begriff ist äquivalent zu einer Top-Level-Transaktion in Semiramis.

Sub-Transaktionen werden bezüglich des Sperrens nicht beachtet. Die Existenz einer Sperre ist an den Kontext gebunden, in dem die Sperre angefordert wird. Für verschiedene Funktionen werden unterschiedliche Typen von Sperren verwendet. Die Einteilung in Typen ist abhängig von der Ressource, dem Kontext und der Funktion der Sperre.

5.1        Sperr-Typen

Hinweis:

Sperren können weiterhin gemäß ihrer Bedeutung klassifiziert werden.

Folgende Sperr-Typen stehen zur Verfügung:

• Use Lock (Nutzungs-Sperre):

Ein Use Lock hat informativen Charakter. Diese Sperre beschreibt, dass eine Ressource von mindestens einem Kontext benutzt wird. Sie können mehr als eine Nutzungs-Sperre für eine Ressource anfordern.

• Exclusive Lock (Exklusiv-Sperre)

Ein Exclusive Lock kann nur einem Kontext zugeteilt werden. Die Zuteilung erfolgt nur dann, wenn kein Use Lock auf der gleichen Ressource angemeldet ist.

Im Transaktionskontext gibt es Read- und Write Locks.

• Read Lock (Lese-Sperre)

Ein Read Lock verhält sich wie ein Use Lock. Lese-Sperren auf Instanzebene werden in Semiramis nur dann angefordert, wenn ein Objekt mit „REPEATABLE_READ“ gelesen wird.

• Write Lock (Schreib-Sperre)

Ein Write Lock verhält sich wie ein Exclusive Lock.

• Logische Sperren

Logische Sperren sind durch eine Zeichenkette identifiziert. Sie sperren keine Ressourcen, sondern haben nur eine Bedeutung für die Anwendung, die diese verwenden. Logische Sperren sind immer Exclusiv-Sperren und sind ausdrücklich anzufordern. Wie alle anderen Sperren sind auch logische Sperren an die Existenz des Kontextes (Job, Transaktion) gebunden, in dem sie angefordert werden.

5.2        Sperr-Arten

Die folgenden Sperr-Arten wurden zur Umsetzung der in Semiramis für das Sperren benötigten Funktionalität definiert:

Sperr-Arten

Activation Group Class Use Lock

Der Application Code Class Loader erzeugt für jede Anwendung eine Java-Klasse mit einer Sperre dieser Art. Java-Klassen für Business Objects, Parts und Views werden nicht durch diese Sperr-Art behandelt, sondern durch die Sperr-Art „JobClassUseLock“. Alle Jobs, die mit dem gleichen Class Loader gestartet werden, sind in der gleichen Activation Group vorhanden. Ein Class Loader lädt eine in sich konsistente Menge von Java-Klassen, die alle einer Version angehören. Eine Activation Group wird gelöscht, wenn ihr kein Job mehr zugeordnet ist. Die Sperren der Art „Activation Group Class Use Lock“ liegen innerhalb der Activation Group und werden freigegeben, wenn die Activation Group gelöscht wird.

Job Class Use Lock

Die Benutzung von Java-Klassen für Business Objects, Parts und Views in einem Job wird durch den Object Manager registriert und über die Sperr-Art „Job Class Use Lock“ verwaltet. Die Sperre wird in dem Kontext des Jobs definiert. Sie wird freigegeben, wenn der Job beendet wird.

Job Class Exclusive Lock

System-Tools erzeugen neue Java-Klassen für Business Objects, Parts oder Views. Damit die Klassen durch eine neue Version ersetzt werden können, wird diese zunächst durch andere Jobs gesperrt. Dazu wird die Sperr-Art „Job Class Exclusive Lock“ verwendet. Die Freigabe dieser Sperr-Art erfolgt, wenn der Job beendet wird. Diese Sperr-Art kann nur angefordert werden, wenn keine andere Sperre der Art „Job Class Lock“ für die Klasse vorliegt.

Job Object Use Lock

Wenn eine Transaktions-Sperre angefordert wird, also wenn eine oder mehrere Instanzen eines Business Object in einer Transaktion benutzt werden, dann wird die Sperr-Art „Job Object Use Lock“ für die Instanzen des Business Object auf einer Datenbank gesetzt. Die Sperre dieser Art wird erst dann freigegeben, wenn alle Transaktions-Sperren freigegeben wurden, die eine solche Sperre angefordert haben.

Job Object Exclusive Lock

Die Sperr-Art „Job Object Exclusive Lock“ wird ausdrücklich von einem Job angefordert, der alle Instanzen eines Business Object in einer Datenbank reserviert, z. B. für die direkte Manipulation einer Tabelle über Datenbank-Statements. Eine Sperre dieser Art ist ausdrücklich vom Job freizugeben. Sie kann nur angefordert werden, wenn keine andere Sperre der Art „Job Object Lock“ für die Instanzen vorliegt.

Job Logical Lock

Eine Sperre der Art „Job Logical Lock“ wird ausdrücklich von einem Job angefordert. Diese kann nur angefordert werden, wenn keine andere Sperre der Art „Logical Lock“ für die zu sperrende Zeichenkette vorliegt. Die Sperre dieser Art muss ausdrücklich freigegeben werden.

Transaction Key Read Lock

Die Sperr-Art „Transaction Key Read Lock“ sperrt eine Gruppe von Business-Object-Instanzen. Die Gruppe wird durch einen Teil eines mehrteiligen Schlüssels identifiziert (Subkey). Für diese Gruppe wird eine Lese-Sperre gesetzt, die ausdrücklich innerhalb einer Transaktion angefordert wird. Die Freigabe erfolgt beim Beenden der Transaktion. Bei jeder Transaktions-Sperre werden automatisch für alle kürzeren Subkeys auch Transaction Key Read Locks angefordert.

Transaction Key Write Lock

Die Sperr-Art „Transaction Key Write Lock“ sperrt eine Gruppe von Business-Object-Instanzen. Die Gruppe wird durch einen Teil eines mehrteiligen Schlüssels identifiziert (Subkey). Für diese Gruppe wird eine Schreib-Sperre gesetzt, die ausdrücklich innerhalb einer Transaktion angefordert wird. Die Freigabe erfolgt beim Beenden der Transaktion.

Transaction Instance Read Lock

Eine Sperre der Art „Transaction Instance Read Lock“ wird nur dann angefordert, wenn ein Business Object mit dem Befehl REPEATABLE_READ gelesen wird.

Transaction Instance Write Lock

Eine Sperre der Art „Transaction Instance Write Lock“ wird nur dann angefordert, wenn ein Business Object mit dem Befehl READ_UPDATE oder READ_WRITE gelesen wird.

Abhängigkeiten

Einige dieser Sperr-Arten sind voneinander abhängig, weil sie Objekte des gleichen Typs auf unterschiedlichen Granularitäts-Ebenen sperren. Allein die Sperr-Art Activation Group Class Use Lock fällt aus dieser Betrachtung heraus. Beachten Sie folgenden Regeln und Abhängigkeiten:

• Einer Sperre auf einer feinen Granularitäts-Ebene gehen Sperren auf allen gröberen Ebenen voraus.
• Der Typ einer Transaktions-Sperre wird an alle Transaktions-Sperren gröberer Granularität als Lese-Sperre weitergegeben.
• Bei jeder Transaktions-Sperre werden für alle kürzeren Subkeys Sperren der Art „Transaction Key Read Lock“ angefordert.
• Eine Nutzungs (Use)- oder Lese-Sperre wird gewährt, wenn keine Exklusiv- oder Schreib-Sperre auf der gleichen Ebene gewährt wurde.
• Eine Exklusiv- oder Schreib-Sperre wird nur gewährt, wenn keine andere Sperre auf der gleichen Ebene gewährt wurde.

Die folgende Tabelle enthält eine Einordnung der Sperr-Arten bezüglich ihrer Funktion im System:

5.3        Implizite Sperren im Object Manager

Im Object Manager werden nur beim lesenden Zugriff Sperren der Art „Transaction Instance Lock“ angefordert und zwar nach den folgenden Regeln:

Wenn Sie mit dem Primärschlüssel Daten lesen, fordern Sie die Sperre direkt mit diesem Schlüssel an. Bei Anforderungen mit einem Sekundärschlüssel ist zunächst der Primärschlüssel zu berechnen. Danach wird die Sperre mit dem Primärschlüssel ausgeführt.

Wenn die Sperre gewährt wurde, wird das Objekt nochmals gelesen, weil beim ersten Lesen das Objekt noch nicht gesperrt war und gegebenenfalls zwischenzeitlich geändert wurde. Der Lock Manager gewährleistet, dass dieses zweite Lesen aktuelle Daten liefert.

Algorithmus

Object object = om.getObject (secondary Key)

AquireLock (object)

object = om.getObject (secondary Key)

Vorteil

Vorteilhaft ist die Schnelligkeit bei interaktiven Anwendungen, die zunächst mit READ gelesen werden und erst eine Sperre beim Schreiben anfordern.

Nachteile

Das Objekt wird, wenn es nicht im Shared Cache zur Verfügung steht, zweimal von der Datenbank gelesen.

Dadurch dass eine andere Transaktion den Sekundärschlüssel des Objekts zwischen dem ersten Lesen und dem Anfordern der Sperre verändern kann, wird das falsche Objekt gesperrt und gelesen. Da die Sekundärschlüssel kaum oder nie verändert werden, ist dieses Vorgehen unproblematisch. Sonst führt dieses Vorgehen natürlich zu inkonsistenten Daten.

Bei zeitabhängigen Objekten wird der Primärschlüssel gesperrt. Damit werden alle Versionen des Objekts gesperrt, weil alle Objekte zeitabhängig sind.

5.4        Logische Sperren

Logische Sperren werden in Semiramis auf Job- und Anwendungs-Ebene verwendet. Im Unterschied zu den nicht logischen Sperren, die Ressourcen im System sperren, sperrt eine logische Sperre eine Zeichenkette, die für eine anwendungsspezifische Semantik steht. Wenn eine logische Sperre für eine Zeichenkette in einem Kontext besteht, dann wird keinem anderen Kontext eine Sperre für die gleiche Zeichenkette gewährt.

Logische Sperren haben keine Auswirkung auf das Verhalten des Systems, es sei denn, sie werden ausdrücklich abgefragt. Logische Sperren werden ausschließlich von den Anwendungen beachtet. Darüber hinaus haben logische Sperren keine Auswirkungen auf die Sperranfragen der Art „Transaction Instance Lock“.

Anwendungs-Sperren

Logische Anwendungs-Sperren werden vom Application-Manager angefordert und freigegeben. Die Anwendungs-Sperren werden automatisch beim Schließen der Anwendung freigegeben. Keine andere Anwendung und kein anderer Job kann die gleiche Zeichenkette sperren, wenn eine Sperre für eine Anwendung gewährt wurde.

Job-Sperren

Logische Job-Sperren können vom System-Manager angefordert- oder freigegeben werden. Stellen Sie sicher, dass die Anwendung, welche die Sperre angefordert hat, auch diese wieder ausdrücklich frei gibt, da sonst die Sperre so lange bestehen bleibt bis der Job beendet wird. Andere Anwendungen im gleichen Job bekommen ebenso die Job-Sperre gewährt, wenn bereits zuvor einer Anwendung im Job die Job-Sperre gewährt wurde.

Wählen Sie die Zeichenkette so, dass sie auf jeden Fall die beabsichtigte Semantik eindeutig identifiziert. Wenn eine Business-Object-Instanz mit der zu sperrenden Semantik verbunden ist, dann reicht es im Allgemeinen die Hexadezimal-Darstellung der Primärschlüssel-Attribute in die Zeichenkette aufzunehmen (wegen der Eigenschaften von GUIDs).

Der Instance String besitzt keine Informationen über die OLTP-Datenbank und die Klasse des Business Object. Berücksichtigen Sie folgende Punkte bei der Wahl der zu sperrenden Zeichenkette:

• gegebenenfalls Zuordnung zu einer OLTP-Datenbank
• Typ der gesperrten Ressource
• Identifikation der gesperrten Ressource

6              Client-Server

Die Datenbanken und die darin enthaltenen Objekte stellen Ressourcen im Sinne des Sperrens dar. Wenn mehr als ein SAS auf eine Datenbank zugreift, so werden die Ressourcen dieser Datenbank von mehreren SAS gleichzeitg genutzt. Der Zugriff auf diese Ressourcen muss SAS übergreifend koordiniert werden. Für diese Koordination wird ein zentraler Message Server eingesetzt, der zentral eine Sperrtabelle verwaltet. Die Sperrtabelle enthält alle Sperren aller untergeordneten SAS. Jeder Semiramis Application Server fragt seine Sperre von dieser zentralen Sperrtabelle ab. Wenn stets nur ein SAS auf eine Datenbank zugreift, entfällt dieser Abstimmungsprozess und damit auch eine Client-Server-Kommunikation.

Client-Server-Kommunikation

Wenn nur ein SAS pro Datenbank vorgesehen ist, dann benötigen Sie auch nur einen lokalen Lock Manager. Für diesen SAS oder Client sind weitere Kommunikations- oder Synchronisations-Wege nicht notwendig.

In einem System mit mehreren Semiramis Application Servern läuft die Kommunikation grundsätzlich über einen Message Server. Die Kommunikation dieser Clients untereinander wird über den Message Server aufgebaut. Wenn ein Client Informationen von anderen Clients benötigt, dann steht dafür ein Dienst im Message Server zu Verfügung.

6.1        Message Server mit Clients

Wenn mehrere SAS (Clients) mit den gleichen Ressourcen arbeiten, also mit den gleichen Datenbanken und Java-Klassen, dann wird der Zugriff auf diese Ressourcen SAS-übergreifend koordiniert. Die Koordination erfolgt mit Hilfe des zentralen Message Servers und Sperren. Der Message Server enthält eine Sperrtabelle, in der alle Sperren aller zugeordneten SAS verwaltet werden. Jede Sperre wird von dieser zentralen Sperrtabelle vergeben.

Die gewährten Sperren werden lokal in jedem Semiramis Application Server verwaltet. Sperranforderungen werden so für bereits gewährte Sperren nicht erneut an die zentrale Sperrtabelle weitergeleitet. Die Anfragen werden durch die lokale Sperrtabelle beantwortet.

Durch diesen Mechanismus wird die Client-Server-Kommunikation für Sperranforderungen zwischen dem Message Server und den angeschlossenen SAS verbessert.

Die häufigen Sperranforderungen der Clients stellen keine Beeinträchtigungen in der Leistungsfähigkeit des Message Servers dar. Die Clients hingegen sind durch den Kommunikationsaufwand zum Message Server langsamer.

Zwischen dem zentralen Message Server und einem zugeordneten Semiramis Application Server werden die folgenden Nachrichten-Arten ausgetauscht.

Sperranforderungen

Eine Sperranforderung umfasst eine oder mehrere Sperren. Die einzelnen Sperren werden an den Message Server in der Reihenfolge der Anforderung übergeben.

Kann eine Sperre vom Message Server nicht gewährt werden, dann werden auch die folgenden angefragten Sperren nicht weiter bearbeitet. Die bereits gewährten Sperren werden in die lokale Sperrtabelle des SAS eingetragen. Der Message Server teilt mit der Gewährung einer Sperre mit, ob das gesperrte Objekt zwischenzeitlich geändert wurde. Damit wird im Cache festgestellt, ob das gesperrte Objekt noch in der aktuellen Version vorliegt oder ob es von der Datenbank erneut gelesen werden muss.

Sperrfreigaben

Wird ein Kontext, wie eine Transaktion, ein Job oder eine Activation Group, beendet, dann werden alle in diesem Kontext angeforderten Sperren im Block freigegeben. Im zentralen Message Server werden die Cache-Einträge für die freigegebenen Exklusiv-Sperren der zugeordneteten SAS entfernt, da diese Cache-Einträge voraussichtlich ungültig sind. Jede freigegebene Sperre wird bis zur nächsten systemweiten Cache-Synchronisation im Message Server vermerkt.

Cache-Synchronisation

In regelmäßigen Abständen (30 Sekunden) wird eine systemweite Cache-Synchronisation durchgeführt. Die Synchronisation umfasst die Benachrichtigung aller SAS (Clients) eines Systems. Informiert wird über die veränderten Business Objects, für die Schreib-Sperren freigegeben wurden. So werden die nunmehr ungültigen Objekte aus den jeweiligen lokalen Shared Caches entfernt.

Kritische Zustände

Beim Anfordern und Freigeben von Sperren tritt ein kritischer Zustand ein, wenn der Message Server oder ein SAS (Client) beendet wurde. Nachfolgend wird kurz beschrieben, welche Fehler auftreten können:

• Semiramis Application Server (Client)

Wenn der Client beendet wurde, gibt der Message Server alle Sperren frei, die der Client angefordert hat.

• Message Server

Semiramis wird auf allen Clients beendet, da sie ohne die zentrale Sperrtabelle keine weiteren Sperren anfordern können.

6.2        Synchronisation der Shared Caches

Das Ergebnis des Nachrichtenaustausches bzw. der Synchronisation zwischen dem Semiramis Application Server (Client) und dem zentralen Message Server ist ein stets aktueller Shared Cache. Aktuell bedeutet, dass alle 30 Sekunden der Shared Cache aktualisiert wird. So liegen im Schared Cache nur aktuelle Objekte. Ungültige Objekte sind diejenigen, die seit der lezten systemweiten Synchronisation von anderen SAS (exklusiv) gesperrt und freigegeben wurden. Wenn ein Objekt im Shared Cache nicht mehr aktuell ist, wird dieses Objekt bei der nächsten Sperranforderung erneut aus der Datenbank gelesen.

Unabhängig von Cache-Synchronisation, können ohne großen Abgleichaufwand die Caches aller SAS nicht konsistent gehalten werden. Konsistent bedeutet in diesem Zusammenhang, dass zusammengehörige Business Objects, wie z. B. ein Business Entity inklusive Dependents, in der gleichen Version vorliegen.

Fall-Beispiel:

SAS A hält einige, aber nicht alle, Objekte O₁, …, O_n eines Business Entity im Cache vor, während ein SAS B das komplette Business Entity O₁, …, O_m verändert. Wenn SAS A das gesamte Business Entity liest, bekommt er O₁,..,O_n in einer älteren Version, während O_n+1,..,O_m in der aktuellen Version vorliegt.

Damit ist das gesamte Entity inkonsistent.

Die Inkonsistenz lässt sich nur dadurch verhindern, dass mit jedem Lesezugriff zuerst eine Lese-Sperre für das Business Entity angefordert wird. Aus diesem Grund entscheidet die Anwendung selbst, wann konsistente Daten benötigt und mit welchen geeigneten Mitteln diese gelesen werden.

Das Setzen der Sperren kostet auf dem Client relativ viel Rechenleistung und ist im rein lesenden Zugriff häufig nicht notwendig. Die Benutzer benötigen nicht immer absolut zeitnahe und aktuelle Daten. Wenn z. B. die Adresse eines Kunden geändert wird, dann erhalten die anderen Application Server diese neue Information nicht sofort, sondern erst nach 30 Sekunden. Inakzeptabel wäre jedoch, wenn der veraltete Datensatz noch stunden- oder tagelang im Cache der übrigen Semiramis Application Server verbleiben würde. Aus diesem Grund schickt der Massage Server an die SAS in regelmäßigen Abständen (alle 30 Sekunden) eine Nachricht mit den Schlüsseln aller in der Zwischenzeit veränderten Objekte (Cache-Synchronisation).

Damit der Message Server den zugehörigen SAS mitteilen kann, welche Objekte sich seit der letzten Cache-Synchronisation verändert haben, führt der Message Server eine Liste der veränderten Objekte. Diese Liste kann bei einem großen Aufkommen an Änderungen sehr lang werden. Insbesondere Transaktions-Daten, die häufig geschrieben werden, führen im Betrieb zu einem großen Hauptspeicher- und Kommunikationsbedarf. Pflegen Sie deshalb eine Änderungsliste nur für bestimmte Business Objects.

Die Änderungsliste wird bei jedem Freigeben einer Transaktions-Sperre erweitert. Die Änderungsliste ist Teil der zentralen Sperrtabelle im Message Server. Sie wird realisiert, indem die zusätzlichen Attribute „letzter Änderer“ und „Dirty Flag“ pro Sperre und pro SAS der Sperrtabelle hinzugefügt werden. Ein „Dirty Flag“ wird gesetzt, wenn der SAS noch nicht über eine freigebene Sperre informiert wurde. Die Änderungsliste wird erst aus der zentralen Sperrtabelle entfernt, wenn die Informationen über die freigegebenen Sperren an alle SAS übermittelt wurden, also kein „Dirty Flag“ mehr gesetzt ist.

Zusätzlich zur Änderungsliste wird die Liste der zuletzt geänderten Objekte verwaltet, in der die Referenzen auf die zuletzt geänderten Business Objects des ändernden SAS vermerkt sind. Durch eine Sperranforderung und mit Hilfe dieser Liste, stellt der Message Server fest, ob der SAS (Client) das Objekt aktuell im Cache behalten kann. Dazu zwei Fall-Beispiele:

• Wenn in der Liste der zuletzt geänderten Objekte ein Client als letzter Änderer eines Objekts vermerkt ist, dann kann der Client die aktuelle Version dieses Objekts im Cache halten und braucht das Objekt nicht nach der Sperre neu aus der Datenbank lesen.
• Wenn in der Änderungsliste der Client als letzter Änderer vermerkt ist, dann braucht das Objekt nicht neu aus der Datenbank gelesen werden.

Wenn durch eine Sperranforderung oder die Cache-Synchronisation einem Client mitgeteilt wurde, dass ein Objekt ungültig ist, dann wird der Client aus der Änderungsliste der nicht benachrichtigten Clients für das Objekt ausgetragen, also das „Dirty Flag“ entfernt. So wird jeder Client nur einmal pro Änderung benachrichtigt.