Utilisez ces informations pour traiter les problèmes liés aux chargeurs de base de données.
Procédure
- Problème : Le chargeur ne parvient pas à communiquer avec la base
de données. Une exception LoaderNotAvailableException se produit.
Explication : Un échec du plug-in du chargeur est possible
lorsque celui-ci ne parvient pas à communiquer avec le système dorsal
de la base de données. Cette situation peut se produire si la connexion
réseau ou le serveur de base de données est inactif. Le chargeur à écriture
différée met les mises à jour en file d'attente et tente périodiquement d'insérer
les modifications apportées aux données dans le chargeur. Ce dernier doit signaler le problème de
connectivité à l'environnement d'exécution ObjectGrid en générant une exception LoaderNotAvailableException.
Solution : L'implémentation du chargeur doit pouvoir distinguer entre une défaillance
de base de données et une défaillance de chargeur physique.
En cas d'échec lié aux données, une exception LoaderException ou OptimisticCollisionException
doit être générée, alors qu'en cas de défaillance physique du chargeur, une exception
LoaderNotAvailableException doit être générée. ObjectGrid gère ces deux exceptions de manières différentes :
- Si une exception LoaderException est détectée par le chargeur à écriture différée,
celui-ci considère l'exception comme un échec, par exemple si une
clé en double a été identifiée. Le chargeur à écriture différée détaille la mise à jour
et examine chaque enregistrement séparément pour isoler la raison de l'échec. Si une exception
{{LoaderException}} est à nouveau détectée lors de la mise à jour
de l'enregistrement concerné, un enregistrement d'échec de la mise à jour est créé et consigné
dans la mappe des mises à jour ayant échoué.
- Si une exception LoaderNotAvailableException est interceptée par le chargeur à écriture différée,
celui-ci considère que l'échec est dû à l'impossibilité de se connecter à la base de données, par exemple,
lorsque le système dorsal de la base de données est inactif, lorsque la connexion à une base de données
est indisponible ou lorsque le réseau est inactif.
Le chargeur à écriture différée attend 15 secondes,
puis tente à nouveau la mise à jour par lots de la base de données.
Une erreur fréquente consiste
à générer une exception LoaderException alors qu'il doit s'agir d'une exception LoaderNotAvailableException. Dans
ce cas, tous les enregistrements mis en file d'attente dans le chargeur à écriture différée deviennent des enregistrements
de mise à jour ayant échoué, ce qui rend l'isolation des défaillances dans le système dorsal inutile.
- Problème : Lorsque vous utilisez un chargeur OpenJPA avec DB2 dans WebSphere
Application Server, une exception de curseur fermé se produit.
L'exception suivante provient de DB2 et figure dans le fichier journal org.apache.openjpa.persistence.PersistenceException :
[jcc][t4][10120][10898][3.57.82] Invalid operation: result set is closed.
Solution : par défaut, le serveur d'applications attribue à la propriété personnalisée resultSetHoldability la valeur
2 (CLOSE_CURSORS_AT_COMMIT).
Cette propriété amène DB2 à fermer son resultSet/curseur au niveau des limites de la transaction. Pour supprimer l'exception, affectez à la propriété personnalisée, la valeur
1 (HOLD_CURSORS_OVER_COMMIT). Définissez la propriété personnalisée resultSetHoldability dans le chemin suivant dans la cellule
WebSphere
Application Server : .
- Problème DB2 affiche une exception : The current transaction has been rolled
back because of a deadlock or timeout. Reason code "2".. SQLCODE=-911,
SQLSTATE=40001, DRIVER=3.50.152
Cette exception se produit en raison d'un problème de conflit de verrouillage lorsque vous exécutez OpenJPA avec DB2 dans WebSphere
Application Server. Le niveau d'isolement par défaut pour WebSphere
Application Server est Lecture reproductible (RR), qui obtient des verrous de longue durée avec DB2.
Solution :
Définissez le niveau d'isolement Read Committed pour réduire les conflits de verrouillage. Définissez la propriété personnalisée de source de données webSphereDefaultIsolationLevel pour spécifier le niveau d'isolement 2(TRANSACTION_READ_COMMITTED) dans le chemin suivant dans la cellule WebSphere
Application Server : . Pour plus d'informations sur la propriété personnalisée webSphereDefaultIsolationLevel et les niveaux d'isolement de transaction, voir Conditions de définition des niveaux d'isolement de l'accès aux données.
- Problème : Lorsque vous utilisez la fonction de préchargement de JPALoader ou JPAEntityLoader, le message CWOBJ1511 suivant ne s'affiche pas pour la partition dans un serveur de conteneur : CWOBJ1511I: GRID_NAME:MAPSET_NAME:PARTITION_ID (primary) is open
for business.
A la place, une exception TargetNotAvailableException est généré dans le serveur de conteneur qui active la partition définie par la propriété preloadPartition.
Solution : Affectez à l'attribut preloadMode la valeur
true si vous utilisez un chargeur JPALoader ou JPAEntityLoader pour précharger les données dans la mappe. Si la propriété preloadPartition du chargeur JPALoader et JPAEntityLoader a une valeur comprise entre
0 et
total_number_of_partitions
- 1, il tente de précharger les données à partir de la base de données dorsale dans la mappe. Le fragment de code ci-dessous illustre comment l'attribut
preloadMode est défini pour activer le préchargement asynchrone :
BackingMap bm = og.defineMap( "map1" );
bm.setPreloadMode( true );
Vous pouvez également définir l'attribut preloadMode à l'aide d'un fichier XML, comme le montre l'exemple suivant :
<backingMap name="map1" preloadMode="true" pluginCollectionRef="map1"
lockStrategy="OPTIMISTIC" />