Opérations d'écriture
Vous pouvez contrôler manuellement dans quelles circonstances les données de session modifiées sont écrites dans la base de données ou dans une autre instance de WebSphere Application Server. Pour ce faire, utilisez la méthode sync de l'interface com.ibm.websphere.servlet.session.IBMSession. Les modes mise à jour manuelle, servlet fin de service et fréquence d'écriture périodique sont disponibles pour régler une fréquence d'écriture des données de session.
Cette interface hérite de l'interface javax.servlet.http.HttpSession. En appelant la méthode sync à partir de la méthode service d'un servlet, vous envoyez toutes les modifications intervenues dans la session à l'emplacement externe. Quand la mise à jour manuelle est sélectionnée comme mode de fréquence d'écriture, les modifications des données de session ne sont écrites dans un emplacement externe que si l'application appelle la méthode sync. Si la méthode sync n'est pas appelée, les modifications des données de session sont perdues lorsqu'un objet session quitte la mémoire cache du serveur. Lorsque servlet fin de service ou périodique est sélectionné pour le mode de fréquence d'écriture, les modifications des données de session sont écrites chaque fois que la méthode sync est appelée. Si la méthode sync n'est pas appelée, les modifications sont écrites à la fin de la méthode de service ou à un intervalle de temps basé sur le mode de fréquence d'écriture sélectionné.
IBMSession iSession = (IBMSession) request.getSession();
iSession.setAttribute("name", "Bob");
// Forcez l'écriture dans un magasin externe
iSession.sync( )
Si la base de données est hors service ou se connecte difficilement lors d'une mise à jour à des valeurs de session, la méthode sync effectue trois tentatives avant de générer une erreur BackedHashtable.getConnectionError. A chaque échec de tentative de connexion, une exception BackedHashtable.StaleConnectionException est générée et figure dans la méthode sync. Si l'ouverture de la base de données a lieu lors de l'une des trois tentatives, les données de session en mémoire sont conservées et validées dans la base.
Cependant, si la base de données n'est toujours pas active au bout des trois tentatives, les données de session en mémoire ne sont conservées qu'après le prochain contrôle d'invalidation de session. Le contrôle de l'invalidation de session est effectué par une unité d'exécution distincte déclenchée toutes les cinq minutes. Les données en mémoire sont homogènes sauf si une demande de données de session est adressée au serveur entre ces événements. Par exemple, si la demande de données de session est émise durant ces cinq minutes, les données de session précédentes sont envoyées au demandeur.
Les sessions ne sont pas des ressources transactionnelles. Du fait que la méthode sync est associée à une unité d'exécution distincte du client, l'exception générée ne se propage pas à ce dernier, qui s'exécute sur l'unité d'exécution principale. Les données d'intégrité transactionnelles peuvent être gérées à l'aide de ressources de type EJB.