Caching von Referenzdaten aktivieren

Cachegröße steuern

Wenn ein SELECT von einer Transaktion für eine zwischenspeicherbare Tabelle ausgeführt wird, speichert der Cache-Manager die abgerufenen Datensätze sowie die SELECT WHERE-Klausel. Die WHERE-Klause wird als Hashschlüssel verwendet, um das Vorhandensein von zwischengespeicherten Datensätzen zu ermitteln.

Es werden vier verschiedene Komponenten vom Cache-Manager gespeichert:

• Der zwischengespeicherte Datensatz (der vom Cache-Manager als "OBJECT" bezeichnet wird).
• Die WHERE-Klauseln der Abfrage, von denen ein oder kein Datenbanksatz zurückgegeben wurde (worauf der Cache-Manager als "SELECT" verweist).
• Die WHERE-Klauseln der Abfrage, von denen null oder mehr Datenbanksätze zurückgegeben wurden (die vom Cache-Manager als "LIST" bezeichnet werden).
• Die Ergebnisse von COUNT-Abfragen und ihren WHERE-Klauseln (die vom Cache-Manager als "COUNT" bezeichnet werden).
  Hinweis: Falls Sie sich wundern, die Verwendung der Begriffe "SELECT", "LIST" und "COUNT" ist historisch bedingt und bezieht sich darauf, dass die WHERE-Klauseln von den Datenbankmethoden selectWithWhere(), listWithWhere und countWithWhere() verwendet wurden. Dadurch, dass Ihnen diese Begriffe bekannt sind, können Sie die Cachegrenzwerte später in diesem Dokument leichter festlegen.

Betrachten Sie z. B. die folgenden Abfragen für die zwischenspeicherbare Tabelle YFS_ORGANIZATION. Die erste Abfrage (mit der Methode "selectWithWhere()") gibt einen Datensatz zurück (bezeichnen Sie diesen Datensatz mit ORG-3):

   select *
   from yfs_organization
   where organization_code = 'ORG-3'
   

Am Ende der Abfrage speichert der Cache-Manager den Datensatz ORG-3 in einer Java™ -Map, auf die der Cache-Manager als OBJECT verweist. Als Nächstes speichert der Cache-Manager die WHERE-Klausel ("where organization_code = 'ORG-3'") in der SELECT-Java-Map (siehe Diagramm unten). Von der SELECT-Zuordnung wird die WHERE-Klausel (bei der es sich um einen Hashschlüssel handelt) zu einem zwischengespeicherten Datensatz zugeordnet.

Die zweite Abfrage (von der die Methode "listWithWhere()" verwendet wird) für dieselbe Tabelle gibt sechs Datensätze (ORG-1 und ORG-6) zurück:

   select *
   from yfs_organization
   where catalog_organization_code = 'ACME' 
   

Am Ende dieser Abfrage speichert der Cache-Manager die zweite WHERE-Klausel in der LIST-Java-Map und die Datensätze ORG-1, ORG-2, ORG-4, ORG-5 und ORG-6 in OBJECT zusammen mit einer Struktur, die die sechs zwischengespeicherten Datensätze der WHERE-Klausel zuordnet. ORG-3 wird vom Cache-Manager nicht hinzugefügt, da es in der ersten Abfrage bereits zur OBJECT-Zuordnung hinzugefügt wurde.

Abschließend werden die WHERE-Klausel und die Zählungsergebnisse (mithilfe der Methode "countWithWhere()" in der COUNT-Zuordnung gespeichert:

   select count(*) 
   from yfs_organization
   where catalog_organization_code = 'ACME'
   

Im folgenden Diagramm wird eine vereinfachte Cachestrukturversion dargestellt:

Die folgenden Parameter aus der Datei dbclassCache.properties werden vom Cache-Manager standardmäßig zur Steuerung verwendet, wie viele COUNT-Ergebnisse, SELECT WHERE-Klauseln, LIST WHERE-Klauseln und OBJECT-Zuordnung (zwischengespeicherte Datensätze) für die einzelnen Tabellen gespeichert werden können:

   sci.globalcache.count.size=10000
   sci.globalcache.select.size=10000
   sci.globalcache.list.size=10000
   sci.globalcache.object.size=10000
   

Eine zwischenspeicherbare Tabelle kann daher am meisten in der JVM speichern:

• Bis zu 10.000 zwischengespeicherte Datensätze (in der OBJECT-Zuordnung)
• Bis zu 10.000 SELECT WHERE-Klauseln
• Bis zu 10.000 LIST WHERE-Klauseln
• Bis zu 10.000 COUNT-Ergebnisse und ihre WHERE-Klauseln

Sie können die Einstellungen mithilfe der Datei customer_overrides.properties außer Kraft setzen. Sie können z. B. den Grenzwert für den Cache für die Anzahl von YFS_RESOURCE-Datensätzen mit dem folgenden Parameter auf 30.000 erhöhen:

   YFS_RESOURCE.objects=30000

Die Spalte "Zwischengespeicherte Objekte" in der Systemmanagementkonsole > Cacheliste Tabellenebene enthält die Anzahl der Datensätze, die für jede Tabelle zwischengespeichert werden.

Beachten Sie Folgendes, wenn Sie die Standardeinstellungen ändern:

• Jeder zwischengespeicherte Datensatz belegt im JVM-Heapspeicher entsprechenden Speicherbereich. Wenn Sie die Anzahl der zwischen gespeicherten Datensätze erhöhen, müssen Sie sicherstellen, dass die Garbage-Collection weiterhin effektiv und "in einwandfreiem Zustand" erfolgt.
• Umgekehrt sollten Sie das Cache-Limit nicht zu niedrig einstellen, sodass der Cache der Systemsoftware „ Sterling Order Management “ die zwischengespeicherten Tabellen ständig leeren muss

Der Anmeldeprozess für die Benutzerschnittstelle dauert über 30 Sekunden, wenn Sie einen zu niedrigen Wert (z. B. 1.000) für den Cachegrenzwert für die Tabellen YFS_RESOURCE und YFS_RESOURCE_PERMISSION festlegen. Diese beiden Tabellen enthalten über 3.000 Datensätze, die im Rahmen des Anmeldeprozesses gelesen werden. Durch Festlegen eines niedrigen Cache-Limits (weniger als die Anzahl der Datensätze in diesen beiden Tabellen) muss der Cache der Systemsoftware „ Sterling Order Management “ frühere Cache-Datensätze löschen, wenn der Cache voll ist. Dadurch müssen die Datensätze bei der nächsten Anmeldung erneut gelesen werden.

Um den Aufwand für die Cacheverwaltung zu minimieren, wird vom Caching-Mechanismus eine einfache Strategie zur Speicherbereichsverwaltung implementiert. Wenn die Anzahl von zwischengespeicherten Datensätzen für eine Tabelle den oben angegebenen Grenzwert erreicht, wird der Cache der Tabelle vom Cache-Manager initialisiert (oder aktualisiert), damit dieser geleert wird.