Discussion :

[sheura]

Salut tout le monde voilà j'aimerais savoir s'il est possible de sauvegarder des sessions en base. Je m'explique je voudrais sauvegarder les sessions HttpSession en base, c'est à dire tout le contenu des variables de sessions. je ne sais pas maintenant si c'est possible ou pas.
Merci d'avance !


[Modéré par Didier] : ajout de tag dans le titre - Les règles du forum Java

[zekey]

Oui c'est possible en sérialisant l'objet HTTPSession et ses fils dans un BLOB par exemple. Pour plus d'infos regarde des docs sur la sérialisation.

Mais pourquoi veux tu faire cela ?

[sheura]

J'ai entendu parler des HttpSessionListener aussi mais je ne sais pas trop comment les utiliser et comment est ce qu'ils fonctionnent. Ce que je voudrais c'est sauvegarder systématiquement les variables de sessions chaque fois pour n'importe quel utilisateur .

[zekey]

Oui mais à quel moment, dès qu'elle est ajoutée ou une fois de temps de temps.

[sheura]

dés qu'elle est ajouté si possible le but serais de le faire systèmatiquement

[SEMPERE Benjamin]

le probleme avec les HttpSessionListener, c'est que tu vas pouvoir exécuter du code (ton code de sérialization) soit à la création soit à la destruction de ta session http://java.sun.com/products/servlet...nListener.html

[zekey]

Je ne vois pas comment détecter le changement dans la HashMap de la session. Sauf si tu as le controle sur le code source auqul cas, le plus simple est de remplacer tous les request.getSession.setAttribute() par une méthode maison qui en plus fait la sauvegarde.
La sauvgarde elle meme sera faite par la serialisation des objets (transformer un objet en table de bytes) et leur sauvegarde en BLOB.
Mais ca me semble compliqué a recuperer par la suite et surtot savoir quand le recuperer.

Rassures moi le but ce n'est pas de permettre un failover, pour recuperer la session en cas de crash ? Parce que si c'est ca il existe un mecanisme integrer à tomcat 5 par exemple.

[sheura]

Je suis d'accord avec toi mais et à la modification de la variable comment est ce que je peux faire pour la mise à jour. Et si je comprend bien il suffit juste de développer une classe qui impléménet HttpSessionListener e tde mettre mon code de sérialisation à l'intérieur. Comment va se faire la lecture des variables de session une fois sérialisées. Est ce qu'il existe un mécanisme de lecture/ecriture de ses variables à partir d'un même endroit???

[zekey]

Le probleme c'est que je ne comprend l'objectif.

Je dirais mais ca dépend fortement de l'objectif

1) Implemente HTTPSessionListener
- Dans le sessionDestroyed fait une boucle sur toutes les clés/valeurs de la HashMap des attributs. Pour chaque valeur enregistre la dans la DB avec l'objet associé en BLOB
-Dans le sessionCreated fait une boucle sur toutes les clés/valeurs de la DB et fait setAttribute dans la session.

Le probleme etant de savoir qui peut lire quoi.

2) Enregistre le nouveau listener dans ton web.xml

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
    <listener>
        <listener-class>web.util.SessionTimeoutListener</listener-class>
    </listener>

[sheura]

En fait je ne sais pas comment java gère les sessions c'est à dire s'il les sauvegarde dans le système de fichier ou en mémoire ....
L'objectif est d'avoir en base une table avec comme champ (session_id, creation_date, creation_time, session_data, user_id) de cette manière on peut avoir pour un utilisateur connecté ses informations de session. Prenons le cas ou l'application tournerais dans un cluster avec deux ou trois serveurs si les sessions sont sauvegardées dans le système de fichier pour un serveur donné et si l'utilisateur accède à une page sur un autre serveur, il sera difficile de faire suivre ses informations de session.

[sheura]

Tu parles d'objet associé en BLOB de quoi s'agit il exactement ??? Je veux dire de quel objet ? Est ce object session avec toutes ses variables ou un quelconque objet ?

[zekey]

C'est bien ce que je craignais, le mécanisme de partage des sessions dans le cas d'un cluster NE DOIT PAS être implementé par l'utilisateur. Il est natif au serveur d'application consulte donc la doc du serveur d'appli pour voir comment faire. Tomcat 5.5 par exemple est capable de partager les session utilisateur entre plusieur instances. Ainsi le fail over et la montée en charge sont facile à gêrer. Mais vouloir implementer cela toi meme me semble une fort mauvaise idée.

Pour répondre à ta question je ne pense pas que tu puisse faire un set de la HashMap, c'est pour cela que je pensais sauvé le couple cle/value 1 à 1

[sheura]

Dans ce cas à quoi pourrait me servir le fait de sauvegarder ses varibles alors. Et si tu dis que ce mécanisme est natif au serveur d'application je susi d'accord mais seulement je voudrait avoir une application independante du serveur d'application c'est à dire que tu la deploie une seule fois et tu l'utilise pas besoin de faire des config suppléméntaire sur le serveur d'application.


Mais dis moi au fait comment un serveur d'application gère ses sessions?
Ou est ce qu'il les sauvegarde?

[zekey]

Dans ce cas à quoi pourrait me servir le fait de sauvegarder ses varibles alors.

Ben justement c'est la question que je te posais

Et si tu dis que ce mécanisme est natif au serveur d'application je susi d'accord mais seulement je voudrait avoir une application independante du serveur d'application c'est à dire que tu la deploie une seule fois et tu l'utilise pas besoin de faire des config suppléméntaire sur le serveur d'application.

Alors la c'est le probleme, deja tout les serveurs d'appl ne sont pas capable de gerer le fail over ou le partage de session. A ma connaissance tomcat le peut. Mais je suppose que JBoss ou WebSphere enfin tous les serveurs d'appl un peu sérieux.
Concernant la config c'est spécifique.

Mais dis moi au fait comment un serveur d'application gère ses sessions?
Ou est ce qu'il les sauvegarde?

C'est toi qui decide, soit memoire soit disque soit DB


Voici deux articles très interessant sur le sujet mais c'est pour tomcat 5.x
http://www.onjava.com/pub/a/onjava/2...lustering.html
http://www.onjava.com/pub/a/onjava/2...lustering.html

[zekey]

J'ai oublié de dire que Tomcat 5.5 représente une avancée non négligeable sur ce sujet (par rapport au 5.0.x). Pour les autres serveurs d'app je ne peux pas te répondre.

[Sniper37]

Et voilà encore un troisième article

http://www.onjava.com/lpt/a/5444