Discussion :

[cdubet]

Bonjour,

j ai le pb suivant

Avec hibernate, j ai un ehcache qui stocke des donnees issues de tables qui ne bougent pas normalement (ex le nom des services de la societe)

Par contre, je vais devoir faire une petite appli pour pouvoir changer ces donnees quasi statique (en cas de reorganisation par exemple). Pour l instant c est fait a la main via SQL ... on est en phase de beta test

Question. si je changes ces donnees sans passer par hibernate/ehcache le cache ne va pas les prendre en compte (normal) et donc je vais me trainer les anciennes donnees .

J ai lu la doc d ehcache, il y a pas de fonction purge ou reset du cache

Quelle est la solution ? (a part integrer hibernate/ehcache dans l outil de mise a jour, ce qui est pas evident vu que ca sera du quick and dirty-> pas de budget pour cet outil)

[bumbo500]

il me semble bien que c'est un problème du cache de second niveau Hibernate. Enfin, problème... c'est logique que si tu mets la bdd à jour d'un autre façon qu'en passant par le système de cache, celui-ci ne prendra pas en compte les nouvelles données. A ma connaissance il n'y a pas de solution, à part de désactiver le cache de second niveau sur ta première appli.

[fr1man]

Tu pourrais :
- relancer ton appli en cas de mise à jour de ta table
- customiser la durée de vie du cache

[cdubet]

option 1:
Arreter/relancer l appli est certes une solution mais c est un peu lourd ... ca veut dire envoyer a mail a tous les utilsateurs disant qu on est indisponible entre telle et telle heure et a ce moment relancer... C est le marteau pilon pour ecraser une noix

option 2: reduire la duree de vie
J y avais pense. Seul pb, on ne sait pas a quel moment on va avoir le passage des anciennes aux nouvelles donnees (puis que ca depent de l anciennete dans le cache). On sait juste qu au pire ca sera dans X h (si j ai mis X pour TTL)

Le probleme devient carrement bloquant si on a modifie plusieurs choses (pas forcement dans des tables differentes d ailleurs). On pourrait tres bien avoir un champs Y qui a la nouvelle valeur (car pas dans le cache avant ou a expire) et le champs Z qui lui n a pas encore expire et qui va afficher l ancienne valeur!

C est quand meme bizarre que ce type de probleme a ete oublie par hibernate/ehchache

[manblaizo]

Salut,
A mon avis, si la mise à jour des données du cache en l'invalidant à intervalle régulier de temps ne suffit pas à résoudre le problème, il se peut que la mise en place même du cache ne convienne pas pour ces données. Car, vu la description que tu en fais, j'ai l'impression que les données pourraient changer souvent, et auquel cas le cache n'est plus pertinent. Je pense qu'un cache ne devrait être mise en place que pour des tables qui ne sont que très peu mises à jour, et que lorsque ça intervient, l'impact sur l'application doit être réduit le plus possible.
Un autre point, c'est qu'une application devrait être conçue pour ateindre un niveau de performance acceptable sans utilisation de cache, en optimisant par exemple les requêtes, les chargements de collections d'objets, etc. Le cache (de second niveau) n'étant qu'un plus pour certaines situations.
Bon, ça ne résout peut-être pas ton problème, mais j'avais juste envie de livrer cette réflexion. J'espère que ça aide.

[cdubet]

non c est des donnes qui ne bougent normalement pas, par exemple la liste des services de la societe.
Pour l appli principale J2EE/hibernate, c est des donnees en lecture seule

Par contre il faut bien que ces donnees puissent etre modifiees (par ex 1 fois tous les 3 ans) et la on va utiliser autre chose comme appli (non definie a leur qui est, mais du quick & dirty and pas cher ...)

Pour le moment je vois 3 solutions
- arret/redemarrage du server J2EE pour recharger le cache (dur on n ets pas la seule appli sur le serveur)
- mettre des TTL tres faible dans ehcache (<5 min), mais c est pas terrible pour les pb exposes + haut
- coder l outil de mise a jour en integrant ehcache et hibernate (donc maj automatique des cache). Probleme, c est plus de developpement

Il y a aussi bien sur la solution de modifier ehcache mais bon ....

[fr1man]

mettre des TTL tres faible dans ehcache (<5 min)

Je ne vois pas l'intérêt de mettre des durées aussi courtes pour des données qui sont très rarement mises à jour.

[cdubet]

moi non plus ;-)

Je souhaite mettre un TTL long, mais si je met 1 j c a veux dire que mes modifs sur la base (s il y en a) seront prise en compte que dans 24 h au pire
(la encore hypothese que la modif est fait par un prog tiers qui n utilise pas hibernate. Programme utilise tous les 36 du mois pour des donnees qui sont auqsi des constantes, ex liste des services de la societe, liste des pays ...)

Une TTL de 5 min permettrai de faire la mise a jour avec un retard d au pire 5 min, ce qui est acceptable (du moins si on modifie qu une table, cf post ci dessus pour pb si plusieurs tables)

C est vraiment dommage qu il n y ai pas de mecanisme de purge de ehcache :-(

[fr1man]

Avec un TTL aussi faible, le cache n'a plus beacoup d'utilité.

J'aurais plutot mis un TTL de 12 heures par exemple, avec mise à jour des données le soir, quand les utilisateurs ne se servent plus de l'application.
Cependant, si l'appication doit être disponible 24h/24, cela n'a pas de sens.

[BsT]

Euh avec Hibernate 2 il y a :

SessionFactory.evict() :
"evict(Class persistentClass)
Evict all entries from the second-level cache."

[cdubet]

1) TTL de 12h regele en effet une partie du pb, tant qu on n est utilise qu en europe. Mais a terme c est plus le cas
2) evict existe toujours avec hibernate V3. mais ca veut dire que mon appli principale sait qu une mise a jour a ete faite et sait ce qui est ou non dans le cache -> comment savoir ce qui est dans eh cache et ce qui ne l est pas/plus?

[BsT]

Mille excuses,

Sur mon application j'ai une console d'administration alors ajouter une action qui vide le cache, ca ne me coute rien....

Est ce que EHCache est administrable avec JMX ?

Stéphane

[Reizz]

Pour JMX, via le StatisticsServiceMBean d'hibernate on peut déjà accéder aux stats du cache de second niveau. Mais on a aussi fait un petit jmx qui evict et select(*) chacun de nos référentiels présent dans le cache. Je ne sais pas si c'est bien mais c'était facile à faire