Sie können den Cache für die Verwendung des Hibernate-Cache-Plug-in aktivieren, indem Sie Eigenschaftendateien angeben.
Vorbereitende Schritte
- Sie müssen die JPA-Cache-Plug-in-Topologie bestimmen, die Sie verwenden möchten.
Weitere Informationen zu den verschiedenen Konfigurationen finden Sie unter JPA-L2-Cache-Plug-in.
- Sie müssen eine Anwendung haben, die die JPA-APIs verwendet. Wenn Sie die APIs von
WebSphere eXtreme Scale für den Datenzugriff mit JPA verwenden möchten, verwenden Sie den
JPA-Loader. Weitere Informationen finden Sie im Abschnitt JPA-Loader konfigurieren.
Vorgehensweise
- Wenn Sie WebSphere Application
Server verwenden, speichern Sie die JAR-Dateien (Java-Archiv)
an den entsprechenden Positionen für Ihre Konfiguration.
Das Hibernate-Cache-Plug-in ist in der Datei
oghibernate-cache.jar gepackt und im Verzeichnis
WAS-Stammverzeichnis/optionalLibraries/ObjectGrid installiert.
Wenn Sie das Hibernate-Cache-Plug-in verwenden möchten, müssen Sie die Datei oghibernate-cache.jar
in die Hibernate-Bibliothek einschließen. Schließen Sie die Hibernate-Bibliothek beispielsweise in Ihre Anwendung ein,
müssen Sie auch die Datei oghibernate-cache.jar einschließen.
Wenn Sie eine gemeinsam genutzte Bibliothek definieren, in die Sie die Hibernate-Bibliothek einschließen, müssen Sie die Datei
oghibernate-cache.jar dem Verzeichnis der gemeinsam genutzten Bibliothek hinzufügen.
eXtreme Scale installiert die Datei
cglib.jar nicht in der Umgebung von WebSphere Application
Server.
Wenn Sie vorhandene Anwendungen oder gemeinsam genutzte Bibliotheken haben wie Hibernate, die
von der Datei cglib.jar abhängig sind, suchen Sie die Datei cglib.jar, und fügen Sie sie dem Klassenpfad hinzu.
Enthält Ihre Anwendung beispielsweise alle
JAR-Dateien für die Hibernate-Bibliothek, aber nicht die für Hibernate verfügbare Datei
cglib.jar, müssen Sie die Datei cglib.jar von Hibernate in Ihre Anwendung einfügen.
- Definieren Sie Eigenschaften in Ihrer Datei persistence.xml, um das
Hibernate-Cache-Plug-in zu konfigurieren.
Die Syntax für die Definition von Eigenschaften in der Datei persistence.xml ist wie folgt:
<property name="hibernate.cache.provider_class"
value="com.ibm.websphere.objectgrid.hibernate.cache.ObjectGridHibernateCacheProvider" />
<property name="hibernate.cache.use_query_cache" value="true"/>
<property name="objectgrid.configuration" value="<Eigenschaft>=<Wert>,..." />
<property name="objectgrid.hibernate.regionNames" value="<Regionsname>,.." />
- hibernate.cache.provider_class: Der Wert
der Eigenschaft provider_class ist die Klasse com.ibm.websphere.objectgrid.hibernate.cache.ObjectGridHibernateCacheProvider.
- hibernate.cache.use_query_cache: Zum Aktivieren des Abfragecaches setzen Sie den Wert der Eigenschaft use_query_cache auf true.
Anmerkung: Sie können den Abfragecache nur für integrierte und integrierte domäneninterne Topologien
aktivieren.
- objectgrid.configuration: Verwenden Sie die Eigenschaft "objectgrid.configuration", um die
Cachekonfigurationseingenschaften von eXtreme Scale zu definieren,
einschließlich des Attributs "ObjectGridType", das angibt, wie die Shards im Datengrid verteilt werden.
Sie müssen
einen eindeutigen Wert für die Eigenschaft "ObjectGridName" angeben, um potenzielle Namenskonflikte zu vermeiden.
Die anderen Konfigurationseigenschaften für den eXtreme-Scale-Cache sind optional.
Zum Aktivieren des Write-behind-Cachings verwenden Sie die folgenden
Write-behind-Attribute in der Eigenschaft "objectgrid.configuration".
Wenn Write-behind-Caching aktiviert ist, werden Aktualisierungen vorübergehend in einem
JVM-bezogenen Datenspeicher gespeichert, bis die writeBehindInterval- oder
writeBehindMaxBatchSize-Bedingungen erfüllt sind, wenn die Daten mit einer Flushoperation in den Cache geschrieben werden.
writeBehind=true, writeBehindInterval=5000, writeBehindPoolSize=10, writeBehindMaxBatchSize=1000
Achtung: Wenn writeBehind nicht aktiviert ist, werden
weitere Write-behind-Konfigurationseinstellungen ignoriert.
Weitere Informationen zu den Werten, die Sie
in der Eigenschaft objectgrid.configuration festlegen können, finden Sie unter Konfigurationseigenschaften des JPA-Caches.
- objectgrid.hibernate.regionNames: Die Eigenschaft "objectgrid.hibernate.regionNames" ist optional und muss angegeben werden,
wenn nach der Initialisierung des eXtreme-Scale-Caches regionsNames-Werte definiert werden.
Angenommen, eine Entitätsklasse ist einem regionName-Wert zugeordnet, und die Entitätsklasse
ist weder in der Datei persistence.xml noch in der Hibernate-Zuordnungsdatei enthalten.
Weiter angenommen, die Entitätsklasse hat eine Annotation "Entity".
In diesem Fall wird der regionName-Wert für diese Entitätsklasse beim Laden der Klassen aufgelöst, wenn der eXtreme-Scale-Cache initialisiert wird.
Ein weiteres Beispiel ist die Methode "Query.setCacheRegion(String
regionName)", die nach der Initialisierung des Caches von eXtreme Scale
ausgeführt wird.
In diesen Situationen müssen Sie alle möglichen dynamisch bestimmten Regionsnamen (regionNames) in die Eigenschaft
"objectgrid.hibernate.regionNames" einfügen, damit der eXtreme-Scale-Cache BackingMaps für alle Regionsnamen vorbereiten kann.
- Optional: Zu weiteren Anpassung des vom Cache verwendeten Datengrids können Sie weitere Einstellungen mit XML-Dateien angeben.
Für die meisten Szenarien
reicht die Definition von Cacheeigenschaften aus.
Wenn Sie das vom Cache verwendete ObjectGrid weiter anpassen möchten, können Sie
Hibernate-ObjectGrid-XML-Konfigurationsdateien im Verzeichnis META-INF bereitstellen, wie
z. B. die Datei persistence.xml. Während der Initialisierung
versucht der Cache, diese XML-Dateien zu finden und sie dann zu verarbeiten.
Es gibt drei Typen von ObjectGrid-XML-Konfigurationsdateien für Hibernate:
- hibernate-objectGrid.xml (ObjectGrid-Konfiguration)
Dateipfad: META-INF/hibernate-objectGrid.xml
Standardmäßig hat jede Entitätsklasse einen zugeordneten Regionsnamen (standardmäßig den Namen der Entitätsklasse),
der einer BackingMap-Konfiguration zugeordnet ist, die nach dem Regionsnamen in der ObjectGrid-Konfiguration benannt ist.
Die Entitätsklasse "com.mycompany.Employee" hat beispielsweise standardmäßig
einen zugeordneten Regionsnamen, der der BackingMap "com.mycompany.Employee" zugeordnet ist. Die BackingMap-Standardkonfiguration hat die Einstellungen
readOnly="false", copyKey="false", lockStrategy="NONE" und copyMode="NO_COPY". Sie können einige BackingMaps
mit einer ausgewählten Konfiguration anpassen. Das reservierte Schlüsselwort "ALL_ENTITY_MAPS"
kann verwendet werden, um alle Maps mit Ausnahme der angepassten Maps aus der Datei hibernate-objectGrid.xml darzustellen.
BackingMaps, die nicht in der Datei hibernate-objectGrid.xml aufgelistet sind, verwenden die Standardkonfiguration.
- hibernate-objectGridDeployment.xml (Implementierungsrichtlinie)
Dateipfad: META-INF/hibernate-objectGridDeployment.xml
Diese Datei wird verwendet, um die Implementierungsrichtlinie anzupassen. Wenn Sie bei der Anpassung der Implementierungsrichtlinie
die Datei hibernate-objectGridDeployment.xml bereitstellen, wird die Standardimplementierungsrichtlinie
verworfen. Alle Attributwerte für die Implementierungsrichtlinie werden der bereitgestellten Datei hibernate-objectGridDeployment.xml entnommen.
- hibernate-objectGrid-client-override.xml (ObjectGrid-Clientkorrekturkonfiguration)
Dateipfad: META-INF/hibernate-objectGrid-client-override.xml
Diese Datei wird verwendet, um ein clientseitiges ObjectGrid anzupassen.
Standardmäßig wendet der ObjectGrid-Cache eine Standardkonfiguration für Clientkorrekturwerte an, die den nahen Cache inaktiviert.
Wenn eine Anwendung einen nahen Cache erfordert, können Sie diese Datei bereitstellen und
numberOfBuckets="xxx" angeben. Der Standardclientkorrekturwert inaktiviert den nahen Cache mit numberOfBuckets="0".
Der nahe Cache kann aktiv sein, wenn das Attribut "numberOfBuckets" über die Datei hibernate-objectGrid-client-override.xml auf einen Wert größer als 0 zurückgesetzt wird.
Die Funktionsweise der Datei hibernate-objectGrid-client-override.xml gleicht der der Datei
hibernate-objectGrid.xml: Sie überscheibt oder erweitert die Standardkonfiguration für ObjectGrid-Clientkorrekturwerte.
Je nach konfigurierter eXtreme-Scale-Topologie können Sie jede dieser drei XML-Dateien verwenden, um diese Topologie anzupassen.
Für die Typen EMBEDDED und EMBEDDED_PARTITION können Sie jede der drei XML-Dateien für die Anpassung
des ObjectGrids, der Implementierungsrichtlinie oder der Konfiguration der ObjectGrid-Clientkorrekturwerte
verwenden.
Bei ObjectGrids des Typs REMOTE erstellt der Cache kein dynamisches
ObjectGrid. Vielmehr ruft der Cache ein clientseitiges ObjectGrid vom Katalogservice ab.
Zum Anpassen der Konfiguration für die ObjectGrid-Clientkorrekturwerte können Sie nur eine Datei hibernate-objectGrid-client-override.xml verwenden.
- Optional: (Nur für ferne Konfigurationen) Sie müssen ein externes eXtreme-Scale-System einrichten, wenn Sie einen Cache
mit dem ObjectGrid-Typ REMOTE konfigurieren möchten.
Sie müssen ein externes eXtreme-Scale-System einrichten, wenn Sie einen Cache
mit dem ObjectGrid-Typ REMOTE konfigurieren möchten. Sie benötigen ObjectGrid- und ObjectGridDeployment-XML-Konfigurationsdateien, die auf der Datei
persistence.xml basieren, um ein externes System einrichten zu können.
Beispiele für diese Konfigurationsdateien finden Sie unter
Beispiel: Hibernate-ObjectGrid-XML-Dateien.
Ergebnisse
EMBEDDED- oder EMBEDDED_PARTITION-Konfiguration:
Wenn eine Anwendung gestartet wird, erkennt oder startet das Plug-in automatisch einen Katalogservice, startet einen Container-Server
und stellt die Verbindung zum Katalogservice her.
Das Plug-in kommuniziert anschließend mit dem ObjectGrid-Container und seinen Peers, die in anderen
Anwendungsserverprozessen ausgeführt werden, über die Clientverbindung.
Jeder JPA-Entität wird über den Klassennamen der Entität eine unabhängige BackingMap zugeordnet.
Jede BackingMap hat die folgenden Attribute:
- readOnly="false"
- copyKey="false"
- lockStrategy="NONE"
- copyMode="NO_COPY"
REMOTE-Konfiguration:
Die Implementierungsrichtlinie
wird gesondert von der JPA-Anwendung spezifiziert.
Ein externes ObjectGrid-System hat Katalogservice- und Container-Server-Prozesse.
Sie müssen einen Katalogservice starten, bevor Sie Container-Server starten.
Weitere Informationen finden Sie unter Eigenständige Server starten und unter Container-Server starten.
Nächste Schritte
- Entwickeln Sie eine Hibernate-Anwendung, die die Konfiguration verwendet. Weitere Informationen finden Sie im Abschnitt Beispiel: Hibernate-Plug-in zum vorherigen Laden von Daten in den ObjectGrid-Cache verwenden.
- Erstellen Sie in einer Produktionsumgebung Katalogservicedomänen für
Ihre automatisch erstellten Prozesse für die EMBEDDED- bzw. EMBEDDED_PARTITION-Konfiguration.
- Eigenständige Umgebung:
Wenn Sie Ihre Server nicht in einem Prozess
von WebSphere Application
Server ausführen,
werden die Hosts und Ports der Katalogservicedomäne über eine Eigenschaftendatei mit dem Namen
objectGridServer.properties angegeben. Diese Datei muss im Klassenpfad der Anwendung
gespeichert werden und die definierte Eigenschaft catalogServiceEndPoints haben.
Die Katalogservicedomäne wird unabhängig von den Anwendungsprozessen gestartet und muss vor den Anwendungsprozessen gestartet werden.
Das Format der Datei objectGridServer.properties ist wie folgt:
catalogServiceEndPoints=<Hostname1>:<Port1>,<Hostname2>:<Port2>
- Umgebung mit WebSphere Application
Server:
Wenn Sie in einem Prozess von
WebSphere Application
Server arbeiten,
stellt das JPA-Cache-Plug-in automatisch eine Verbindung zum Katalogservice bzw. zur Katalogservicedomäne her,
der bzw. die für die Zelle von WebSphere Application
Server definiert ist.
- Wenn Sie den ObjectGridTyp-Wert EMBEDDED oder EMBEDDED_PARTITION
in einer Java-SE-Umgebung verwenden, verwenden Sie am Ende des Programms die Methode
System.exit(0), um den integrierten eXtreme-Scale-Server zu stoppen.
Andernfalls reagiert das Programm möglicherweise nicht mehr.