Arnaud Thimel a écrit :
Alors je viens d'avoir au téléphone un utilisateur de cette application et d'après ce qu'il me décrit, c'est tout à fait de là que vient le problème !
En effet, en fonction du rootContext que j'utilise sur l'application, j'ai des infos plus ou moins à jour (certaines sont carrément obsolètes). Ca s'explique assez bien : chaque rootContext a sa session Hibernate, et donc un état potentiellement désynchronisé avec la base. Je fais une mise à jour sur un des rootContext, la mise à jour arrive bien en base, par contre quand je demande une info à un autre context, si jamais ce context avait déjà chargé cette info et bien si il l'a encore en cache, il renvoie l'info obsolète.
Est-ce que vous validez ma théorie ?
Arnaud.
Ouaip et elle m'arrange aussi, le prob c'est que tu va (ou julien) avoir du taf, tu viens de résoudre le bug de Philippe, je pense que ses suivis tour normalement supprimé le sont pour lui que plus tard, donc le problème venais de nous... Bon courage !
Arnaud Thimel a écrit :
Salut,
Dans une application nous ouvrons plusieurs 'rootContext'. Ils sont différenciés car l'objet Properties utilisé pour la récupération du context varie. Il varie, mais tous les rootContext pointent sur la même base. Est-ce que ça ne peut pas être source à problème ?
D'autre part, dans le TopiaContextFactory, j'ai trouvé ça : static public TopiaContext getContext(Properties config) throws TopiaNotFoundException { TopiaContextImpl result = contextCache.get(config); if (result == null || result.isClosed()) { result = new TopiaContextImpl(config); contextCache.put((Properties) config.clone(), result); } }
Comme le "equals" de Properties fait un "deep equals", j'ai l'impression que le .clone() ne sert à rien ?
Arnaud.