Eviter la désynchronization d'un cache en Java

Salut à tous :D,

J'ai une question algo d'ordre général. Voici rapidement le contexte. J'ai un serveur de base de données (MSSQL Server) et un serveur frontal pour attaquer cette base de données. Ceci permet de fournir une librairie permettant d'interagir avec la base sans avoir à faire de SQL mais uniquement par le biais d'une librairie orientée objet (au fait, nous sommes en Java).

Dans mon application, j'utilise donc la librairie (dblib.jar par exemple) pour accéder à ma base et remonter les données sous forme d'objets (des "DBObject" par exemple). Pour savoir quand un objet est supprimé/modifié ou créé en base, il faut donc que j'écoute les événements de mon serveur frontal. A ce dessein, la couche de persistence de mon application contient un cache de DBObjects.

Le problème c'est que pour modifier un objet dans mon serveur frontal, je dois donner un "delta" et non pas l'objet tel qu'il devrait être. C'est à dire ne fournir au serveur que les données qui ont changé, que celles ajoutées et que celles supprimées. L'invariant n'est pas transmis. Donc entre le moment où je crée mon "delta" et le moment où la librairie 'dblib.jar' se charge de transmettre ma requête, la base de donnée a été mise à jour par quelqu'un d'autre et ma requête est refusée. Par exemple si je dis qu'une variable "A" est ajoutée dans mon delta alors qu'elle existe déjà en base mais que je n'étais pas encore au courant, ça va planter ma requête. C'est sans doute un problème courant et j'aimerais avoir des avis sur ce genre de choses.

La solution la plus bidon : refaire la requete quand on détecte une désynchro (et on la détecte facilement, l'exception renvoyée dans ce cas est très éloquente). Je précise que l'architecture ne peut être changée, notre produit se base sur une architecture dont nous ne sommes pas propriétaires.

Merci à tous les motivés du lundi qui auront le courage de tout lire ;)

c'est le problème des accès concurrents, je connais pas beaucoup de solutions mise à part les transactions pour s'assurer de l'intégrité des données et de refaire ta requête qui a échoué ... ou alors de comparé entre les données modifiés par A et les nouvelles données modifiés par B et de mettre à jour uniquement celles qui ne sont pas dans cette "liste"

Merci pour ta réponse. En effet une des rares solutions qui me vienne à l'esprit est de recommencer la requête. Mais dans ce cas là, ça veut dire qu'il faut re-créer mon delta à un niveau applicatif ; la couche de persistence n'est pas capable de le refaire toute seule car je ne lui passe pas d'objet de référence mais directement le delta. En d'autres termes, la couche de persistence ne sais pas si elle doit écraser les données avec le contenu du delta ou bien intégrer les nouvelles données dans le delta pour qu'elles soient conservées.

Mon point de vue : minimiser le temps entre la création du delta et la requete auprès du serveur frontal et éviter l'utilisation d'un cache semblent être les meilleurs choix. Et en défense, refaire la requête. Comme ça on peut déléguer le calcul du delta à la couche de persistence et refaire la requête ne pose pas de problème particulier au niveau applicatif, c'est transparent. Quant au bénéfice du cache, il est perdu mais bon, les omelettes, les oeufs, tout ça....... Je flag "résolu" mais si d'autres personnes peuvent apporter leur expérience du sujet, j'en serais heureux ;)