Petit doute sur le multi rootContext
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. -- Société Code Lutin http://www.codelutin.com tel : 02 40 50 29 28 fax : 09 59 92 29 28
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. 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.
-- Société Code Lutin http://www.codelutin.com tel : 02 40 50 29 28 fax : 09 59 92 29 28
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.
On Thu, 28 May 2009 15:46:16 +0200 Arnaud Thimel <thimel@codelutin.com> wrote:
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 ?
En fait le .clone sert surtout a etre sur qu'aucun code externe va modifier le properties a l'exterieur ce qui impliquerait des problemes pour le TopiaContextFactory. Si vous souhaitez 2 root contexte vraiment different et que vous avez exactement le meme fichier de propriete. Je pense que le mieux est d'ajoute une entre dans le fichier de configuration genre. dans le 1er fichier de propriete context.number=1 et dans le deuxieme context.number=2 de cette facon, le TopiaContextFactory ne retournera pas le meme TopiaContext pour les deux fichiers de propriete. Mais je ne sais pas si je repond exactement au probleme :( Pour revenir 2s sur le clone, je me demande s'il ne devrait pas etre fait plus tot (avant l'appel du new TopiaContextImpl (a bien reflechir) -- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii
Le Sat, 30 May 2009 12:09:39 +0200, Benjamin POUSSIN <poussin@codelutin.com> a écrit :
On Thu, 28 May 2009 15:46:16 +0200 Arnaud Thimel <thimel@codelutin.com> wrote:
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 ?
En fait le .clone sert surtout a etre sur qu'aucun code externe va modifier le properties a l'exterieur ce qui impliquerait des problemes pour le TopiaContextFactory.
Si vous souhaitez 2 root contexte vraiment different et que vous avez exactement le meme fichier de propriete. Je pense que le mieux est d'ajoute une entre dans le fichier de configuration genre.
dans le 1er fichier de propriete context.number=1 et dans le deuxieme context.number=2
de cette facon, le TopiaContextFactory ne retournera pas le meme TopiaContext pour les deux fichiers de propriete.
Mais je ne sais pas si je repond exactement au probleme :(
Pour revenir 2s sur le clone, je me demande s'il ne devrait pas etre fait plus tot (avant l'appel du new TopiaContextImpl (a bien reflechir)
Dans ObServe, je fais un clone avant de récupérer un rootContext pour être sûr d'être bien isolé de tout changement dans le properties. On devrait rajouter dans la javadoc de la méthode de TopiaContextFactory une note technique pour indiquer ce clone.
-- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii _______________________________________________ Topia-devel mailing list Topia-devel@lists.labs.libre-entreprise.org http://lists.labs.libre-entreprise.org/mailman/listinfo/topia-devel
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Le .clone c'est une chose. Mais je m'interrogeait surtout sur la pertinence d'utiliser 2 rootContext ? En admettant que je tape sur 2 bases différentes, ok. Par contre 2 contextes sur une même base, si ça entraine les problèmes de désynchronisation entre les 2 contextes (entre les 2 sessions Hibernate si on est sur une impl Hibernate), j'ai peur que ce soit systématiquement une mauvaise idée ? Sachant que pour mon problème actuelle, la différence entre les 2 contexte vient des propriétés propres à la sécurité. Arno. Benjamin POUSSIN a écrit :
On Thu, 28 May 2009 15:46:16 +0200 Arnaud Thimel <thimel@codelutin.com> wrote:
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 ?
En fait le .clone sert surtout a etre sur qu'aucun code externe va modifier le properties a l'exterieur ce qui impliquerait des problemes pour le TopiaContextFactory.
Si vous souhaitez 2 root contexte vraiment different et que vous avez exactement le meme fichier de propriete. Je pense que le mieux est d'ajoute une entre dans le fichier de configuration genre.
dans le 1er fichier de propriete context.number=1 et dans le deuxieme context.number=2
de cette facon, le TopiaContextFactory ne retournera pas le meme TopiaContext pour les deux fichiers de propriete.
Mais je ne sais pas si je repond exactement au probleme :(
Pour revenir 2s sur le clone, je me demande s'il ne devrait pas etre fait plus tot (avant l'appel du new TopiaContextImpl (a bien reflechir)
-- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii _______________________________________________ Topia-devel mailing list Topia-devel@lists.labs.libre-entreprise.org http://lists.labs.libre-entreprise.org/mailman/listinfo/topia-devel
-- Société Code Lutin http://www.codelutin.com tel : 02 40 50 29 28 fax : 09 59 92 29 28
participants (4)
-
Arnaud Thimel -
Benjamin POUSSIN -
letellier -
Tony Chemit