Discussion :

[gribo]

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.

[fr1man]

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.

[gribo]

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"...

[fr1man]

une légende "informatique" prétend qu'Hibernate flush sa session "quand il veut"...

Le flush n'est pas fait au hasard mais selon plusieurs critères.
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()

[djsnipe]

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)

[fr1man]

Dans le cas d'une transaction, l'état sera toujours persisté en BDD après le commit

Oui puisque, par défaut, le commit appelle le flush qui lui est responsable de l'écriture en base.

[gribo]

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.

[djsnipe]

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).