Bonjour,

Je travaille sur une architecture haute disponibilité basée sur une paire de serveurs d'applications WebSphere. Un seul des deux serveurs est utilisé, une bascule est effectuée sur le deuxième en cas de problème. La synchronisation entre les deux serveurs est effectuée en utilisant les mécanismes natifs de WebSphere.
L'application utilise Hibernate pour gérer la persistance des données, et il est envisagé d'utiliser le cache de second niveau et le cache de requêtes.
J'aurais voulu savoir si Hibernate prévoyait des mécanismes exploitables sur ce type d'architecture comme par exemple la possibilité de récupérer la session en cours (en particulier son cache) sur le deuxième serveur ? En cas d'erreur au cours d'une session, qu'advient-il des données cachées ?
Merci d'avance de votre aide.

C.H.

attention cache de premier niveau (session) et de second niveau ne sont pas gérés de la même façon.

Pour le cache de second niveau, documente toi sur le cache JBoss.

Pour la session hibernate.... humm ta question est bizarre.
Quelle est la durée de vie de ta session Hibernate?
Qu'entends tu par haute disponibilité? Repliques tu les session http d'un serveur vers l'autre ou fais tu simplement de la répartition de charge (loadbalancing)?

Oui, excuse-moi, je n'ai pas été super claire dans ma question ;)
Pour le moment je m'interesse uniquement au cache de la session (premier niveau). Pour le cache de second niveau il est envisagé d'utiliser OSCache, je suis en train de creuser ce point.
En fait, nous répliquons les sessions http entre les deux serveurs et nous utilisons également le load balancing. Les deux serveurs sont donc exactement dans le même état au même moment et les utilisateurs attaquent indifféremment l'un ou l'autre.
Je cherche donc à savoir où est stockée la session hibernate et s'il suffit effectivement de répliquer les sessions http pour que les sessions hibernate soient répliquées également ?
D'autre part, j'aurais voulu savoir quand le cache de session est-il mis à jour ? J'ai compris que le flush synchronise la source de données persistante (donc la base de données) avec le contenu de la session, mais quand et comment est réalisée l'opération inverse (si elle existe) ? En effet, les deux serveurs pouvant être utilisés pour attaquer la base de données au même moment, que se passe-t-il si l'un modifie une donnée de la base que l'autre a en session hibernate ?
Quelles règles de "bonnes pratiques" conseillerais-tu d'appliquer pour le développement d'une application (à base d'EJB Sessions stateless) utilisant hibernate executée dans ce type d'environnement ?
Merci d'avance de ton aide :)

C'est à toi de le savoir lol, Hibernate n'est pas lié au type d'application web. Donc si tu décides d'utiliser le pattern long session per application transaction, il y a de forte chance que tu passes par la session HTTP.
Par contre DANGER, il n'est pas recommandé d'utiliser ce pattern si tu fait de la replication de session HTTP, et oui le traffic réseau engendré peut te foutre en l'air tes performances.
Dans ce cas, mais Emmanuel l'expliquera mieux que moi, il est préférable d'éviter de trop utiliser la session HTTP, cela passe par les opérations de détachement ré attachement des instances persistances et c'est le pattern session per http request.

L'opération inverse du flush? ça s'appelle récupération et rafraichissement des instances persistantes et ça se produit à chaque fois que tu fait get, load, ou que tu executes une requete.
J'ai le sentiments, mais je me trompe peut etre, que tu ne sais pas vraiment quel pattern est utilisé par tes applications. Ce qui est tres dangereux.

[quote]L'opération inverse du flush? ça s'appelle récupération et rafraichissement des instances persistantes et ça se produit à chaque fois que tu fait get, load, ou que tu executes une requete. [/quote]
En fait je me demandais si cela se produisait de manière automatique. Visiblement non. Si je comprends bien, il est nécessaire que les sessions soient les plus courtes possibles afin d'éviter les problèmes d'incohérence entre le cache et la base si les accès concurrents sont nombreux.
Ce que je ne comprend pas encore bien, c'est où sont stockées les informations de la session hibernate si elles sont stockées indépendamment de la session HTTP ? Je n'ai pas trouvé d'informations sur la façon dont on peut forcer ou non hibernate à stocker les infos dans la session HTTP ou ailleurs ?

[quote]J'ai le sentiments, mais je me trompe peut etre, que tu ne sais pas vraiment quel pattern est utilisé par tes applications. Ce qui est tres dangereux.[/quote]
En fait, l'application n'est pas développée encore. Mon objectif est d'identifier les risques posés l'utilisation d'Hibernate sur l'architecture haute dispo dont nous avons besoin, et ensuite de déterminer les patterns permettant de s'affranchir de ces risques (si c'est possible ;).

le guide de référence dit clairement que la session hibernate est non threadsafe et qu'elle doit avoir une durée de vie courte...
Donc oublie de suite la notion de "cache", dis toi que chaque client (client dans ce cas = requête http) aura sa propre session hibernate et devra l'utliser comme unité de travail pour résoudre un cas d'utilisation. Reste à définir comment traiter les cas d'utilisation longs et donc je me répète: si tu dois répliquer les sessions http, tu ne peux te permettre de faire durer ta session hibernate sur plusieurs httpResquest au risque de sacrifier les perfs. Donc opte pour le ré attachement. Ca marche nickel.


Tu penses bien que si Hibernate ne donnait pas satisfaction sur de tels environnements, ça se saurait ;-)
Un conseil consomme ta charge d'étude de faisabilité en charge de formation sur Hibernate, la clé dans un environnement aussi critique est l'expertise.

A priori, tu vas entamer l'étude d'une appli critique. N'hésite pas à envisager l'intervention professionnelle, ne serait ce que pour du conseil, ca coutera pas énorme à ta boite et tu auras les best practice et les conseils de Pros. Tu es à Paris?



Bonne chance et n'hesite pas...