Synchro d'objets issus d'une base de donnée

Bonsoir,

Pour rendre mon problème conpréhensible, je vais prendre un exemple concret. Soit un site d'annonces immobilière avec des users enregistrées (les particuliers vendeurs).

Soit C(n) N clients connectés qui consultent le site. Supposons le scénario suivant :

C(1) liste les annonces de Paris. Il obtient une liste d'annonce.
C(2), en réalité un vendeur, se logue sur ce site. Il modifie son annonce, qui est une maison à 70 000€. Il la passe à 100 000€ et enregistre (l'objet Annonce est mis à jour en base).
C(1) voit dans sa liste justement la fameuse maison à 70 000€. Il clique sur le lien pour le détail de l'annonce. Plusieurs possibilité selon la réalisation de l'application :

1- dans le détail de la page il voit 70 000€. Typiquement quand il a fait sa recherche l'intégralité des annonces retournées ont été stockées dans la session utilisateur. La page de détail affiche donc l'objet issu de la session utilisateur. (je trouve ça pas top)
2- dans le détail de la page il voit 100 000€. Typiquement l'objet est actualisé à chaque appel. (je trouve ça pas top non plus)

Ma question est donc la suivante : existe-t-il un framework, un coding pattern, une autre solution technique... pour synchroniser entre eux différents objets qui sont en réalité le même ? Ou alors, idéalement à mon avis, avoir une seule instance Java pour un seul objet "equivalent" en base de données.

Comment y arriver ? Hibernate permet-il ce genre de truc ? Faut-il créer une classe qui conserve toutes les instances uniques ?...

Merci pour vos éventuels éclairages !

Bonjour titbit,

Je dirais qu'il n'y a pas de solution unique. Elle dépend complétement de ton contexte.

- La maison en question peut être acheter via un click (c'est beau de réver ;)).
Il faut alors que tu modifies le modèle de ta base pour prendre en compte l'historique des prix. Le prix sera donc fonction de la date précise à laquelle le client a récupérer le détail de la maison.

- Le prix de la maison n'est que pour de la consultation.
Dans ce cas, il faudra se baser sur le prix final et donc refaire une requete pour connaitre le vrai prix avant de la mettre dans le panier final de l'utilisateur. Ce prix sera conservé pour pouvoir historiser le panier de l'utilisateur.

Bref autant de choix possible que de contexte fonctionnel.

Je n'avais pas trop pensé au "contexte fonctionnel". Pour moi, ca serait plus ta solution 2.

En fait ce qui me dérangeait le plus c'est de faire de nombreux appels à la BDD. Mais bon, ca sert aussi à ça un SGBD... non ?

@ titbit :

deux choses me paraissent importantes dans ton exemple;
1) le listing des Annonces (donc en lecture seule) ne devrait pas être stockée dans une 'Session', mais bien être de type 'Request', voir même mieu 'Page', cela va permettre qu'a chaque rafraichissement de la page, les données seront déjà plus a jour.

2) sur la page où il a la liste des annonces, et plus particulièrement le lien qui permettrait de signaler que cette annonce m'intéresse, une vérification devrait être active, pour vérifier si au moment ou il clique, si l'annonce n'a pas changé entre temps, ce qui va renforcer la justesse des valeurs.

de toute façon je préconise un Pool de connections pour éviter la gestion lourd des connections/déconnections.

Si tu utilises les EJB3, je dirais que la lecture serait une EJB de type Stateless

en espérant t'avoir aidé.

Perso, pour un projet, j'ai fait ça pour un caddie (ou un panier, c'est comme on veut).

Un EJB @Entity (c'est parce qu'on sauve le caddie en base de données, mais ça peut très bien être un @Stateless) représente le caddie.
Une page JSP affiche le contenu du caddie avec un bouton "acheter". Le caddie est alors mis en session.
Lorsque l'utilisateur clique sur acheter, ça lance la servlet associée à l'action, et cette servlet récupère le caddie de l'ejb, et le caddie de la session, et les compare. S'ils sont différents, c'est que quelqu'un a modifié quelque chose (par exemple l'utilisateur est loggué 2x et a ajouté quelque chose à son caddie), et donc l'achat est annulé (la liste est réaffichée, et il peut recliquer sur acheter).