Utilisation des sessions pour accéder aux données de la grille

Les applications peuvent commencer et terminer les transactions par le biais de l'interface Session. L'interface Session permet également d'accéder aux interfaces ObjectMap et JavaMap d'application.

Chaque instance ObjectMap ou JavaMap est directement associée à un objet Session spécifique. Chaque unité d'exécution souhaitant accéder à eXtreme Scale doit préalablement obtenir une instance Session à partir de l'objet ObjectGrid. Une instance Session ne peut pas être partagée par plusieurs unités d'exécution. WebSphere eXtreme Scale n'utilise aucun stockage local d'unités d'exécution ; cependant, les restrictions de plate-forme risquent de limiter le passage d'une Session d'une unité d'exécution à une autre.

Méthodes

Méthode Get

Une application obtient une instance Session à partir d'un objet ObjectGrid à l'aide de la méthode ObjectGrid.getSession. L'exemple suivant illustre comment obtenir une instance Session :

ObjectGrid objectGrid = ...; Session sess = objectGrid.getSession();

Une fois l'instance Session obtenue, l'unité d'exécution garde une référence à la session pour son propre usage. L'appel de la méthode getSession plusieurs fois renvoie un nouvel objet Session chaque fois.

Transactions et méthodes de session

Une session peut être utilisée pour commencer, valider ou annuler une transaction. Les opérations sur BackingMaps avec ObjectMaps et JavaMaps sont exécutées plus efficacement dans une transaction Session. Une fois une transaction commencée, toute modification apportée à un ou plusieurs mappes de sauvegarde dans cette transaction est stockée dans un cache de transaction spécial jusqu'à ce que la transaction soit validée. Lorsqu'une transaction est validée, les modifications en attente sont appliquées aux BackingMaps et Loaders et deviennent visibles par tous les clients de cet ObjectGrid.

WebSphere eXtreme Scale permet également de valider automatiquement les transactions. Si une opération ObjectMap est effectuée en dehors du contexte d'une transaction active, une transaction implicite est lancée avant l'opération et la transaction est automatiquement validée avant de rendre le contrôle à l'application.

Session session = objectGrid.getSession();
ObjectMap objectMap = session.getMap("someMap");
session.begin();
objectMap.insert("key1", "value1");
objectMap.insert("key2", "value2");
session.commit();
cobjectMap.insert("key3", "value3"); // auto-validation

Méthode Session.flush

La méthode Session.flush est utile lorsqu'un chargeur est associé à une BackingMap. La méthode flush appelle le chargeur avec l'ensemble de modifications actuel dans le cache de transaction. Le chargeur applique les changements au dorsal. Les changements ne sont pas validés lorsque la méthode flush est appelée. Si une transaction de session est validée après l'appel de flush, seules les mises à jour postérieures à l'appel de flush sont appliquées au chargeur. Si une transaction de session est annulée après l'appel de la méthode flush, les modifications vidées sont annulées, de même que toutes les autres modifications en attente dans la transaction. Utilisez la méthode flush avec parcimonie car elle limite les opérations de traitement par lots pour un chargeur. L'exemple ci-dessous illustre l'utilisation de la méthode Session.flush :

Session session = objectGrid.getSession();
session.begin();
// faites des modifications supplémentaires
...
session.flush(); // envoyez ces modifications vers le programme de chargement, mais
// ne validez pas ces modifications supplémentaires
...
session.commit();

Méthode NoWriteThrough

Certaines cartes sont sauvegardées par un chargeur, qui fournit un stockage de persistance aux données dans la mappe. Il est parfois utile de valider les données uniquement dans la mappe eXtreme Scale et de ne pas envoyer les données au chargeur. L'interface de session fournit la méthode beginNoWriteThough dans ce but. La méthode beginNoWriteThrough commence une transaction comme la méthode begin. Avec la méthode beginNoWriteThrough, lorsque la transaction est validée, les données sont uniquement validées dans la mappe mémoire et elles ne sont pas validées dans le stockage de persistance fourni par le chargeur. Cette méthode est particulièrement utile lors du préchargement des données sur la mappe.

Lors de l'utilisation d'une instance ObjectGrid répartie, la méthode beginNoWriteThrough est utile pour effectuer des modifications dans le cache proche uniquement, sans modifier le cache éloigné du serveur. Si les données sont périmées dans le cache proche, l'utilisation de la méthode beginNoWriteThrough peut permettre d'invalider les entrées sur le cache proche sans les invalider sur le serveur.

L'interface Session fournit également la méthode isWriteThroughEnabled pour déterminer quel type de transaction est actuellement actif.

Session session = objectGrid.getSession();
session.beginNoWriteThrough();
// faites des modifications supplémentaires...
session.commit(); // ces modifications ne seront pas envoyées au chargeur

Obtention de la méthode d'objet TxID

L'objet TxID est un objet opaque qui identifie la transaction active. Utilisez l'objet TxID pour les applications suivantes :

  • Pour effectuer des comparaisons lorsque vous recherchez une transaction spécifique.
  • Pour stocker des données partagées entre les objets TransactionCallback et Loader.

Reportez-vous au plug-in TransactionCallback et aux chargeurs pour des informations supplémentaires sur la fonction d'attribut Object.

Méthode de suivi des performances

Si vous utilisez eXtreme Scale dans WebSphere Application Server, il peut être nécessaire de réinitialiser le type de transaction pour le suivi des performances. Vous pouvez définir le type de transaction avec la méthode setTransactionType. Pour plus d'informations sur la méthode setTransactionType, reportez-vous à la section concernant le suivi des performances d'ObjectGrid par le biais de l'infrastructure d'analyse des performances (PMI) de WebSphere Application Server.

Exécution de la méthode LogSequence

WebSphere eXtreme Scale peut propager des ensembles de modifications de mappe en programmes d'écoute ObjectGrid pour répartir les mappes d'une machine virtuelle Java à une autre. Pour que le programme d'écoute puisse traiter les LogSequences plus facilement, l'interface Session fournit la méthode processLogSequence. Cette méthode examine chaque LogElement dans l'objet LogSequence et effectue l'opération appropriée, par exemple une insertion, une mise à jour, une invalidation, etc. sur la BackingMap identifiée par LogSequence MapName. Une session ObjectGrid doit être disponible avant l'appel de la méthode processLogSequence. L'application a également la responsabilité d'effectuer les appels de validation ou d'annulation appropriés pour terminer la session. L'auto-validation n'est pas disponible pour cet appel de méthode. Le traitement normal par l'ObjectGridEventListener récepteur au niveau de la JVM distante est de démarrer une session en utilisant la méthode beginNoWriteThrough, qui empêche la propagation sans fin des modifications , puis d'appeler la méthode processLogSequence, et enfin de valider et d'annuler la transaction.

// Utilisez l'objet Session transmis au cours de
//ObjectGridEventListener.initialization...
session.beginNoWriteThrough();
// traitez la LogSequence reçue
try {
	session.processLogSequence(receivedLogSequence);
} catch (Exception e) {
	session.rollback(); throw e;
}
// validez les modifications
session.commit();

Méthode markRollbackOnly

Cette méthode est utilisée pour marquer la transaction actuelle en tant que "rollback only" (annulation uniquement). En marquant la transaction "rollback only", vous vous assurez que, même si la méthode de validation est appelée par une application, la transaction est annulée. Cette méthode est généralement utilisée par ObjectGrid lui-même ou par l'application lorsqu'une corruption de données est susceptible de se produire si la transaction est validée. Une fois cette méthode appelée, l'objet Throwable transmis à cette méthode est chaîné à l'exception com.ibm.websphere.objectgrid.TransactionException qui résulte de la méthode de validation si elle est appelée sous une session précédemment marquée comme "rollback only". Tout appel ultérieur de cette méthode pour une transaction déjà marquée en tant que "rollback only" est ignoré. Cela signifie que seul le premier appel transmettant une référence Throwable non nul est utilisé. Une fois la transaction marquée terminée, la marque "rollback only" est supprimée afin que la prochaine transaction lancée par la session soit validée.

Méthode isMarkedRollbackOnly

Renvoie un résultat si Session est marquée "rollback only". Cette méthode renvoie la valeur booléenne True si et uniquement si la méthode markRollbackOnly a été précédemment appelée sur cette Session et si la transaction commencée par cette Session est toujours active.

Méthode setTransactionTimeout

Définissez le délai d'attente de la prochaine transaction démarrée par cette Session sur un nombre spécifique de secondes. Cette méthode n'affecte pas le délai d'attente des transactions précédemment commencées par cette Session. Cela affecte uniquement les transactions lancées après l'appel de la méthode. Si cette méthode n'est jamais appelée, la valeur de délai d'attente passée à la méthode setTxTimeout de la méthode com.ibm.websphere.objectgrid.ObjectGrid est utilisée.

Méthode getTransactionTimeout

Cette méthode renvoie la valeur de délai d'attente de la transaction, exprimée en secondes. La dernière valeur passée en tant que valeur de délai d'attente à la méthode setTransactionTimeout est renvoyée par cette méthode. Si la méthode setTransactionTimeout n'est jamais appelée, la valeur de délai d'attente passée à la méthode setTxTimeout de la méthode com.ibm.websphere.objectgrid.ObjectGrid est utilisée.

transactionTimedOut

Cette méthode renvoie une valeur booléenne si le délai d'attente de la transaction actuelle commencée par cette Session a été dépassé.

Méthode isFlushing

La méthode renvoie la valeur booléenne True si et uniquement si toutes les modifications de transaction sont vidées vers le plug-in Loader comme conséquence de la méthode de vidage de l'interface Session appelée. Cette méthode peut être utile à un plug-in Loader lorsqu'il doit savoir pourquoi la méthode batchUpdate a été appelée.

Méthode isCommitting

Cette méthode renvoie la valeur booléenne True si et uniquement si toutes les modifications de transaction sont validées comme conséquence de la méthode de validation de l'interface de Session appelée. Cette méthode peut être utile à un plug-in Loader lorsqu'il doit savoir pourquoi la méthode batchUpdate a été appelée.

Méthode setRequestRetryTimeout

Cette méthode définit, en millisecondes, la valeur de délai d'attente avant la prochaine tentative de requête pour la session. Si le client définit une valeur de délai d'attente avant la prochaine tentative de requête, le paramètre de la session remplace la valeur du client.

Méthode getRequestRetryTimeout

Cette méthode récupère le paramètre de délai d'attente avant la prochaine tentative de requête sur la session. La valeur -1 indique que le délai d'attente n'est pas défini. La valeur 0 indique qu'il est en mode d'interruption immédiate. Une valeur supérieure à 0 indique le paramètre de délai d'attente, en millisecondes.