IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

JDBC Java Discussion :

Eviter la désynchronization d'un cache en Java


Sujet :

JDBC Java

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre averti
    Profil pro
    Inscrit en
    Février 2005
    Messages
    13
    Détails du profil
    Informations personnelles :
    Âge : 44
    Localisation : France

    Informations forums :
    Inscription : Février 2005
    Messages : 13
    Par défaut Eviter la désynchronization d'un cache en Java
    Salut à tous ,

    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

  2. #2
    Inactif  
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    2 189
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : Suisse

    Informations forums :
    Inscription : Mai 2006
    Messages : 2 189
    Par défaut
    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"

  3. #3
    Membre averti
    Profil pro
    Inscrit en
    Février 2005
    Messages
    13
    Détails du profil
    Informations personnelles :
    Âge : 44
    Localisation : France

    Informations forums :
    Inscription : Février 2005
    Messages : 13
    Par défaut
    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

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Systèmes de caches en Java
    Par vinzzzz dans le forum Général Java
    Réponses: 5
    Dernier message: 13/08/2013, 13h30
  2. Cache applicatif Java avec taglib
    Par abe63 dans le forum Taglibs
    Réponses: 1
    Dernier message: 04/10/2010, 16h30
  3. Gérer le cache de Java pour les images
    Par JavaMan77 dans le forum Applets
    Réponses: 0
    Dernier message: 14/12/2008, 23h49
  4. outOfMemory Java heap size : cache configuration ?
    Par will82 dans le forum Hibernate
    Réponses: 4
    Dernier message: 23/08/2006, 11h47
  5. Comment eviter de dedoubler projet c++ et projet java/applet
    Par buzzz dans le forum Langages de programmation
    Réponses: 8
    Dernier message: 13/10/2004, 13h02

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo