Vous pouvez activer le cache pour utiliser le plug-in de cache Hibernate en définissant des fichiers de propriétés.
Avant de commencer
- Vous devez déterminer la topologie du plug-in de cache JPA à utiliser. Voir Plug-in de cache niveau 2 (L2) JPA pour plus d'informations sur les différentes configurations.
- Vous devez disposer d'une application utilisant les API JPA. Si vous souhaitez utiliser les API WebSphere eXtreme Scale pour accéder aux données avec JPA, utilisez le chargeur JPA. Pour plus d'informations, voir
Configuration des chargeurs JPA.
Procédure
- Si vous utilisez WebSphere
Application Server, placez les fichiers JAR (Java Archive) dans les emplacements appropriés.
Le plug-in de cache Hibernate est regroupé dans le fichier oghibernate-cache.jar et installé dans le répertoire racine_was/optionalLibraries/ObjectGrid.
Pour utiliser le plug-in de cache Hibernate, vous devez inclure le fichier oghibernate-cache.jar dans la bibliothèque Hibernate. Par exemple, si vous incluez la bibliothèque Hibernate dans votre application, vous devez également inclure le fichier oghibernate-cache.jar.
Si vous définissez une bibliothèque partagée pour inclure la bibliothèque Hibernate, vous devez ajouter le fichier oghibernate-cache.jar dans le répertoire de cette bibliothèque partagée.
eXtreme Scale n'installe pas le fichier cglib.jar dans l'environnement WebSphere
Application Server.
Si vous avez des applications existantes ou des bibliothèques partagées comme Hibernate, qui dépendent de cglib.jar, localisez le fichier cglib.jar et incluez-le dans le chemin d'accès aux classes. Par exemple, si votre application inclut tous les fichiers JAR de la bibliothèque Hibernate, mais exclut le fichier cglib.jar fourni avec Hibernate, vous devez inclure le fichier cglib.jar fourni par Hibernate dans votre application.
- Définissez les propriétés dans le fichier persistence.xml pour configurer le plug-in de cache Hibernate.
Syntaxe de la définition des propriétés dans le fichier persistence.xml :
<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="<property>=<value>,..." />
<property name="objectgrid.hibernate.regionNames" value="<regionName>,.." />
- hibernate.cache.provider_class : la valeur de la propriété provider_class est la classe com.ibm.websphere.objectgrid.hibernate.cache.ObjectGridHibernateCacheProvider.
- hibernate.cache.use_query_cache : pour activer le cache des requêtes, affectez la valeur true à la propriété use_query_cache.
Remarque : Vous pouvez activer le cache des requêtes pour les topologies intradomaines intégrées et non intégrées uniquement.
- objectgrid.configuration : utilisez la propriété objectgrid.configuration pour définir les propriétés de configuration du cache eXtreme Scale, y compris l'attribut ObjectGridType qui indique comment placer les fragments dans la grille de données.
Vous
devez spécifier une valeur de propriété ObjectGridName unique pour éviter les conflits de
nom.
Les autres propriétés de configuration du cache d'eXtreme Scale sont facultatives.
Pour activer la mise en cache en écriture différée, utilisez les attributs d'écriture différée suivants dans la propriété objectgrid.configuration. Lorsque la mise en cache en écriture différée est activée, les mises à jour sont provisoirement stockées dans une mémoire de données de portée JVM jusqu'à ce que la condition writeBehindInterval ou writeBehindMaxBatchSize soient respectées lorsque les données sont vidées dans le cache.
writeBehind=true, writeBehindInterval=5000, writeBehindPoolSize=10, writeBehindMaxBatchSize=1000
Avertissement : Les autres paramètres de configuration de l'écriture différée sont ignorés sauf si writeBehind est activé.
Pour plus d'informations sur les valeurs que vous pouvez définir dans la propriété objectgrid.configuration, voir Propriétés de configuration du cache JPA.
- objectgrid.hibernate.regionNames : la propriété objectgrid.hibernate.regionNames est facultative et doit être définie lorsque les valeurs regionNames sont définies après l'initialisation du cache eXtreme Scale. Prenons l'exemple d'une classe d'entité mappée sur une valeur regionName dont la classe d'entité n'est pas spécifiée dans le fichier
persistence.xml ou n'est pas incluse dans le fichier de mappage Hibernate. En outre, cette classe d'entité comporte une annotation d'entité. La valeur regionName pour cette classe d'entité est ainsi résolue
au moment du chargement de la classe lors de l'initialisation du cache d'eXtreme Scale. La méthode Query.setCacheRegion(String
regionName) exécutée après l'initialisation du cache d'eXtreme Scale illustre également cette configuration.
Dans ces situations, incluez toutes les éventuelles valeurs regionNames déterminées de façon dynamique dans la propriété
objectgrid.hibernate.regionNames de sorte que le cache d'eXtreme Scale puisse préparer les mappes de sauvegarde pour toutes les valeurs regionNames.
- Facultatif : Pour personnaliser davantage la grille de données utilisée par le cache, vous pouvez fournir des paramètres supplémentaires avec des fichiers XML.
Dans
la plupart des cas, la définition des propriétés du cache est amplement suffisante.
Toutefois, si vous souhaitez peaufiner la personnalisation de la grille d'objets utilisée par le cache, vous pouvez mettre à disposition dans votre répertoire META-INF des fichiers XML de configuration de Hibernate ObjectGrid, à la manière du fichier persistence.xml. Pendant l'initialisation, le cache tente de localiser ces fichiers XML et les traite s'il les trouve.
Il existe trois types de fichiers XML de configuration Hibernate ObjectGrid :
- hibernate-objectGrid.xml (configuration ObjectGrid)
Chemin du fichier : META-INF/hibernate-objectGrid.xml
Par défaut, chaque classe d'entité est associée à une valeur regionName (par défaut au nom de la classe d'entité) mappée sur une configuration BackingMap désignée sous regionName au sein de la configuration de l'ObjectGrid. Par exemple,
la classe d'entité com.mycompany.Employee est associée à une valeur regionName
qui a la valeur par défaut com.mycompany.Employee BackingMap. La configuration BackingMap
par défaut est readOnly="false", copyKey="false", lockStrategy="NONE" et copyMode="NO_COPY".
Vous pouvez tout à fait personnaliser des
mappes de sauvegarde avec la configuration que vous choisissez. Le mot clé réservé ALL_ENTITY_MAPS
représente tous les mappages à l'exclusion des mappages personnalisés répertoriés
dans le fichier hibernate-objectGrid.xml.
Les mappes de sauvegarde qui ne figurent pas dans ce fichier
hibernate-objectGrid.xml utilisent la configuration par défaut.
- hibernate-objectGridDeployment.xml (stratégie de déploiement)
Chemin du fichier : META-INF/hibernate-objectGridDeployment.xml
Ce fichier sert à personnaliser la règle de déploiement. Lorsque celle-ci est personnalisée,
si le fichier hibernate-objectGridDeployment.xml est fourni, la règle de déploiement par défaut est ignorée. Toutes les valeurs d'attribut de la règle de déploiement proviennent du fichier hibernate-objectGridDeployment.xml fourni.
- hibernate-objectGrid-client-override.xml (configuration de remplacement
ObjectGrid client)
Chemin de fichier : META-INF/hibernate-objectGrid-client-override.xml
Ce fichier sert à personnaliser un ObjectGrid côté client. Par défaut,
le cache de l'ObjectGrid applique une configuration par défaut de remplacement par les clients,
qui désactive le cache local. Si l'application a besoin
d'un cache local, elle peut fournir ce fichier en y spécifiant numberOfBuckets="xxx".
Le remplacement de client par défaut désactive le cache local en définissant numberOfBuckets="0".
Pour activer le cache local, il suffit de donner à numberOfBuckets une valeur
supérieure à 0 dans le fichier hibernate-objectGrid-client-override.xml.
Le fonctionnement du fichier hibernate-objectGrid-client-override.xml est semblable à celui du fichier hibernate-objectGrid.xml :
Il substitue ou étend la configuration par défaut des remplacements ObjectGrid par les clients.
Pour personnaliser cette topologie, vous pouvez fournir le fichier XML adapté au type de l'
eXtreme Scale configuré.
Pour le type EMBEDDED comme pour le type EMBEDDED_PARTITION, vous pouvez fournir n'importe lequel de ces trois fichiers XML pour personnaliser
la grille d'objets, la règle de déploiement et la configuration des remplacements par les clients ObjectGrid.
Dans le cas d'un ObjectGrid REMOTE, le cache ne crée pas d'ObjectGrid dynamique.
Le cache ne contient en fait qu'un ObjectGrid côté client provenant du service de catalogue.
Dans ce cas, vous ne pouvez fournir qu'un fichier hibernate-objectGrid-client-override.xml qui personnalisera la configuration de la substitution de l'ObjectGrid client.
- Facultatif : (Configurations distantes uniquement) Définissez un système eXtreme Scale externe si vous voulez configurer un cache avec un type REMOTE ObjectGrid.
Afin de pouvoir configurer un cache d'ObjectGrid de type REMOTE, vous devez configurer un système externe eXtreme Scale. Pour configurer ce système externe, vous aurez besoin des deux fichiers XML de configuration ObjectGrid et
ObjectGridDeployment basés sur un fichier persistence.xml. Pour des exemples de ces fichiers de configuration, voir Exemple : fichiers XML ObjectGrid Hibernate.
Résultats
Configuration EMBEDDED ou EMBEDDED_PARTITION :
Lors du démarrage d'une application, le plug-in détecte automatiquement un service de catalogue ou en démarre un, démarre un serveur de conteneur et connecte les serveurs de conteneur au service de catalogue. Le plug-in communique alors avec le
conteneur ObjectGrid et ses homologues exécutés dans d'autres processus de
serveur d'applications à l'aide de la connexion client.
Chaque entité JPA
possède une mappe de sauvegarde indépendante affectée à l'aide du nom de
classe de l'entité. Chaque mappe de sauvegarde possède les attributs ci-après.
- readOnly="false"
- copyKey="false"
- lockStrategy="NONE"
- copyMode="NO_COPY"
Configuration REMOTE :
La règle de déploiement est spécifiée séparément de l'application JPA. Un système ObjectGrid externe comporte le service de catalogue et les processus serveur de conteneur. Vous devez démarrer le service de catalogue avant les serveurs de conteneur. Pour plus d'informations,
reportez-vous aux rubriques Démarrage des serveurs autonomes et Démarrage des serveurs de conteneur.
Que faire ensuite
- Développez une application Hibernate qui utilise la configuration. Pour plus d'informations, voir Exemple: Utilisation du plug-in Hibernate pour précharger les données dans le cache ObjectGrid.
- Dans un environnement de production, créez des domaines de service de catalogue pour vos processus automatiquement créés pour votre configuration.
- Environnement autonome :
Si vous n'exécutez pas vos serveurs dans un processus WebSphere
Application Server,
les hôtes et les ports du domaine de service de catalogue sont spécifiés à l'aide du fichier de propriétés objectGridServer.properties. Ce fichier doit
être stocké dans le chemin d'accès aux classes de l'application et la propriété
catalogServiceEndPoints doit être définie. Le domaine de service de catalogue est démarré indépendamment des processus d'application et doit être démarré avant les processus d'application.
Le
format du fichier objectGridServer.properties est le
suivant :
catalogServiceEndPoints=<hostname1>:<port1>,<hostname2>:<port2>
- Environnement WebSphere
Application Server :
Lors d'une exécution à l'intérieur d'un processus WebSphere
Application Server, le plug-in de cache JPA se connecte automatiquement au service de catalogue (ou au domaine de service de catalogue) qui est défini pour la cellule WebSphere
Application Server.
- Si vous
utilisez le type de grille d'objets EMBEDDED ou
EMBEDDED_PARTITION dans un environnement Java SE, utilisez la méthode
System.exit(0) à la fin du programme pour arrêter le serveur
eXtreme Scale imbriqué. Sinon, le programme peut ne pas répondre.