Version imprimable
Bonjour,
J'ai une application web qui utilise hibernate et un cache de second niveau.
Que se passe-t-il si d'autres applications mettent à jour ma base sans passer par hibernate ?
Il m'arrive de faire des maj directement dans la base et j'ai l'inconvénient que mon application web ne les voit pas directement, mais y'a-t-il un risque qu'une mise à jour via le web écrase une mise à jour effectuée via un batch ?
Merci d'avance pour vos retours d'expérience.
Le cache Hibernate ne sera pas au courant des mises à jour effectuées par une autre application.
Fais tu ces mises à jour n'importe quand dans la journée, ou à heure fixe ?
Selon le cas, tu peux jouer avec la durée de vie de ton cache, pour que les modifications soient visibles.
Il y a risque d'écrasement si tu travailles sur un même enregistrement.
Non, je ne fais pas des traitements à heure fixe.
Pour l'écrasement le scénario qui m'inquiète est le suivant :
1 - Je modifie un enregistrement via hibernate, valeur "A" que je change en "B".
J'ai terminé ma transaction.
La valeur est modifiée en cache mais pas en BD car hibernate flush la session quand il veut parait-il.
2 - Je modifie la valeur "A" directement en Base et je lui donne la valeur "C".
3 - Hibernate X temps plus tard, synchronise son cache avec sa base et ecrase la valeur "C" en BD avec sa valeur "B" du cache.
Pour moi l'etape 3 ne doit jamais se produire, au moment de la synchro du cache avec la base, Hibernate doit voir que "C" est arrivé après "B" et doit donc mettre à jour le cache à "C" plutot que de mettre la valeur "B" en base.
Quelqu'un peut-il me confirmer ou m'infirmer cela ?
Mon exemple est-il clair ?
Je compte faire un test, mais ce n'est pas evident sachant qu'une légende "informatique" prétend qu'Hibernate flush sa session "quand il veut"...
J'ajouterai que dès lors que l'on met en place un cache il faut se poser 2 questions :
1) Les données mises en cache peuvent-elles être modifiées par quelqu'un d'autre ?
2) Quelle politique d'invalidation du cache : FIFO, LRU, à une heure fixe chaque jour, procédure manuelle ...
Si la réponse à la 1ère question est oui, il faut déterminer quand l'application doit prendre en charge la modification :
1.1) Tout de suite ==> soit il ne fallait pas mettre en cache, soit il faut prévoir un mécanisme d'invalidation du cache qui soit transactionnel avec la mise à jour pour garder la cohérence.
1.2) Après un certain délai ==> donc l'importance de la politique d'invalidation du cache. Par exemple, si la donnée en cache est un paramétrage quelconque, on peut considérer qu'il est acceptable de le prendre en compte uniquement le lendemain. Mais là ATTENTION, si la donnée en question n'était pas en cache, ce sera pris en compte tout de suite, le cache aura un impact sur le fonctionnement de l'application, ce sera dur à diagnostiquer en cas de bug ! (c'est pas du vécu, mais c'est tout comme).
Le flush n'est pas fait au hasard mais selon plusieurs critères.Citation:
une légende "informatique" prétend qu'Hibernate flush sa session "quand il veut"...
Je te conseille de lire la documentation sur ce sujet.
Le flush peut être fait :
- par un appel explicite à la méthode session.flush()
- par un commit() de la transaction qui implicitement effectuera un flush()
Dans le cas d'une transaction, l'état sera toujours persisté en BDD après le commit. Et le flush n'y change rien, (bon ok, sauf si le mode d'isolation transactionnel à été mis à TRANSACTION_READ_UNCOMMITED, mais c'est rare, voire à proscrire, mais c'est un autre débat)
Oui puisque, par défaut, le commit appelle le flush qui lui est responsable de l'écriture en base.Citation:
Dans le cas d'une transaction, l'état sera toujours persisté en BDD après le commit
OK Merci pour votre éclairage.
La "légende informatique" vient bien de personnes utilisant Hibernate hors de tout cadre transactionnel.
Mais avec JTA ou Spring je pensais bien que le cache ne viendrait pas écraser des données commitées en BD après mise en cache.
Je marque la discussion comme résolue.
Cela ne veut pas dire grand chose, dans la mesure ou toute action vers une base a lieu dans une transaction.Citation:
La "légende informatique" vient bien de personnes utilisant Hibernate hors de tout cadre transactionnel.
Simplement, certains utilisent le mode autocommit de JDBC qui masque cela.