Discussion :

[NikoBe]

Bonjour,

Je voudrais savoir s'il existe un design patern pour empêcher la création de plusieurs instances d'un objet pour une même session jsp.

En gros je voudrais donc étendre le principe du Singleton (http://java.developpez.com/faq/java/..._Singleton_def).
Avec un singleton on ne peut avoir qu'une seule instance de l'objet en tout et pour tout (grâce à l'attribut private static principalement).
Dans mon cas, il faudrait pouvoir créer plusieurs instances de cet objet, mais max une par session. Si l'instance existe déjà, renvoyer l'instance existante.

Un tout grand merci d'avance à quiconque pourrait m'aider !

[Sniper37]

Bonjour,

Je voudrais savoir s'il existe un design patern pour empêcher la création de plusieurs instances d'un objet pour une même session jsp.

En gros je voudrais donc étendre le principe du Singleton (http://java.developpez.com/faq/java/..._Singleton_def).
Avec un singleton on ne peut avoir qu'une seule instance de l'objet en tout et pour tout (grâce à l'attribut private static principalement).
Dans mon cas, il faudrait pouvoir créer plusieurs instances de cet objet, mais max une par session. Si l'instance existe déjà, renvoyer l'instance existante.

Un tout grand merci d'avance à quiconque pourrait m'aider !

tu n'a même besoin de singleton si je ne m'abuse, un objet en session est unique et ne sera pas partager par d'autres sessions, sauf si tu fais des new un peu partout.

[roudoudouduo]

Dans ton message il me semble que tu confonds bcp de choses :
- la durée de vie d'un objet en session est égale à la durée de la session définie par ton container web.

Tu n'as pas besoin d'un design pattern, mettre un objet en session en utilisant le request.getSession().setAttribute() fait exactement ce travail.

Apres si tu as reelement besoin de mutaliser le code d'accès, un pattern util basé sur la session me semble convenir à ta problématique.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
   XUtil {
      private static final String XNAME = "xname";
 
       pubilc static X createOrLoadXFromSession(HttpServletRequest request){
           if(request == null){
                throw new IllegalArgumentException();    
           }
           final X x = getX(request);
           request.getSession().setAttribute(XNAME , x);
           return x;
      }
 
     private static X getX(HttpServletRequest request){
           if(request.getSession().getAttribute(XNAME) == null){
                 return new X();
           }
          return (X)request.getSession().getAttribute(XNAME);
    }
   }

Pour parler conception, le singleton est un anti-pattern de mon point de vue. En effet la durée de vie d'un objet ne dois pas dépendre de lui même mais de l'utilisation que l'on en fait. Les problèmes de synchronisation liée aux singletons sont nombreux et il vaux mieux réfléchir à deux fois avant de l'utiliser.

[link256]

Dans la pratique tu testes si ta session contient le dit objet et si oui tu le récupère dans le cas contraire tu le place en session.


Problème que j'ai déjà eu à partir d'un portail applicatif qui donne accès à une application mais avec 2 mécanisme différents celon les objets en sessions, je rencontrait des disfonctionnements.

Ceci était dù à 2 choses les objets stocké en session sont au niveau de la page appelante qui était mon portail et non spécifique à la nouvelle fenêtre pour l'application et des utilisateurs qui clic que la croix de l'explorateur au lieu de cliquer sur le lien 'quitter' qui nettoyait la session.

Solution à chaque nouvelle connexion utilisateur je vérifie la présence ou non de certaint objet et je purge ma session pour en avoir une 'propre'.
Et ainsi evité des erreurs qui sortent de tous les cadres de cas d'utilisation possible.

[NikoBe]

OK, merci pour vos réponses.
Celle de Roudoudouduo me semble la plus adéquate à mon problème.

Pour rendre les choses plus concrètes, voici exactement ce qui me concerne:
Lors du chargement d'une page jsp, j'initialise un thread (et je le "start") qui va gérer un timeout sur une opération.
Le problème est que si l'utilisateur reload la page, un nouveau thread est créé et starté. C'est ceci que je veux éviter.

[link256]

Tu ne peux pas vérifier l'état de ton thread avant de le 'starter' ?

[Sniper37]

OK, merci pour vos réponses.
Celle de Roudoudouduo me semble la plus adéquate à mon problème.

Pour rendre les choses plus concrètes, voici exactement ce qui me concerne:
Lors du chargement d'une page jsp, j'initialise un thread (et je le "start") qui va gérer un timeout sur une opération.
Le problème est que si l'utilisateur reload la page, un nouveau thread est créé et starté. C'est ceci que je veux éviter.

Si le bean est en session, il sera créer une seule fois, même si l'utilisateur reload la page.