Djebel1 a écrit :
Clairement pour les raisons d'architecture que tu évoques ça le fait pas trop de mettre l'objet en session. Je voulais plutôt dire "spécifique à chaque utilisateur" que "spécifique à une session".
Ce que je souhaiterais, c'est que le singleton soit propre à chaque utilisateur, donc que la variable statique stocke plusieurs objets d'accès à la base, un par utilisateur, que ça soit un peu un "pool" de connections à la base.
Mais comment faire ça de manière propre ? Par exemple je pourrai faire remonter un identifiant d'utilisateur jusqu'à la couche d'accès aux données, mais c'est pas super propre je trouve.
Peut-être faut-il que je me tourne vers les threads ? Une variable statique est-elle partagée entre threads ?
(je pensais par défaut qu'avec tomcat chaque utilisateur lançait un thread différent, qui ne partageaient pas d'infos entre eux, visiblement je me trompe quelque part ... je pourrais donc éventuellement faire en sorte que chaque requête utilisateur lance un thread différent, mais ... ça marcherait ? )
|
Personnellement, j'éviterais de trafiquer avec les threads. ça donne des solutions élégantes et courtes, mais difficilement comprises par d'autres ; sans doute à cause du côté "contexte magique", transverse... Je laisse l'argumentation là, n'étant pas expert de ce genre d'implémentation, duquel je m'éloignes autant que possible ; en dépit du côté pratique indéniable.
Tel que tu présentes le problème, je me demande si une solution de ce type ne pourrait pas être satisfaisante :
Code :
- class Contexts {
- private Map contexts = new HashMap();
- private static Contexts instance;
- public static Contexts getInstance() {
- if (instance == null) instance = new Contexts();
- return instance;
- }
- private Contexts() {}
- public Context getContext(User u) { return (Context) contexts.get(u); }
- ...
- }
|
Il s'agit bien d'un Singleton, qui gère des contextes utilisateur. Il reste à définir ce qu'est un User au sens métier, et un Context au sens de ton application. Un contexte pourrait contenir diverses informations, préférences, etc.
J'étudierais dans quelle mesure utiliser un ID de session HTTP est une bonne / mauvaise clé pour identifier un User, ou si un nom d'utilisateur, numéro de qqch (INSEE, SIREN, FINESS...) est plus approprié.
Pour le contexte, je me poserais la question de la montée en charge : combien d'utilisateurs, combien d'objets dans le contexte, quelle lourdeur en moyenne pour chaque objet, etc.
De façon générale, je me poserais la question de ce qui rends les données propres à un utilisateur.
Ce ne sont que des pistes.
Message édité par Cherrytree le 09-06-2007 à 18:14:53