Rendre dispo un objet pendant la tt la session

**brousaille** · 17/01/2005, 15h08

Bonjour a tous,

Voila comme vous avez surement put le lire dans un autre thread j'essai de me former la main sur J2EE. Et la je bloque sur un pb de conception, j'espere que vous allez pouvoir m'aider.

Voila je voudrai avoir un objet connection disponible pendant toute la session et qu'il soit initialiser au lancement de l'application, donc pour ca j'ai crée un servlet qui se charge au démarage de tomcat. C'est dans cette partie que je doit initialiser et rendre disponible ma connection a la database.

Au départ je pensais mettre cette objet dans la context Servlet, mais ca me parrait pas tres bon, car des que je voudrais utiliser la connection , dans ma couche "Business" par exemple (Connection c = getConnection() ), il faudrait toujours que je passe le context en parametre pour qu'il puisse la trouver !!!

Je pense qu'il doit y avoir une meilleur méthode, pourriez vous m'aider merci beaucoups par avance

B.

Config :

Eclipse 2.1.3
Tomcat 5.0.28

**viena** · 17/01/2005, 15h18

A ta place, je mettrais en place un singleton.
De cette façon, tu n'est meme pas obligé de la chargé au départ de ton appli.
Quand tu as besoin de ta connexion, tu utilises ton singleton qui te renvoie la connexion. Au premier appel de ton singleton, il crée ta connexion, sinon, il la renvoie juste.

**brousaille** · 17/01/2005, 15h22

oui je peux faire ca aussi, c'est vrai et c'est surement plus propre mais ma question est la suivante comment le faire persister............ c'est la que je bloque ??

**thibaut** · 17/01/2005, 15h27

Salut,

A mon avis le problème de conception n'est pas là:

Pourquoi conserver ton objet Connection tout au long de la session ?

Cela me semnle être une pratique dangereuse : imagine que tu ne libère pas correctement cet objet connection (plantage serveur ou autre), et bien au bout de quelques temps et avec plusieurs utilisateurs simultanés, ta base va rapidement crier car elle n'aura plus de connections disponilbes...

Garder un objet connexion implique une programmation très propres pour libérer cet objet dans tous les cas de figure...

A mon avis tu pourrais et tu ferais mieux d'utiliser un pool de connection...

A+

**brousaille** · 17/01/2005, 15h39

oui tu as surement raison, mais bon imagine que les parametres ma connection soient dans un XML. Je ne vais pas aller parser le fichier a chaque fois que je demande un connection ?

Je pense que tu seras d'accord avec ca, et c'est pourquoi je me demande comment faire persister cet objet qui contiendrait tout mes parametres de connection ?

**thibaut** · 17/01/2005, 15h44

Dans ce cas utilises tu as deux solutions:

- utiliser un pool de connections,
- lire les paramètres de connection une fois pour toutes au démarrage de ton appli (et les conserver car c'est moins dangereux de ne pas libérer quelques String

).

**brousaille** · 17/01/2005, 15h45

Yes thibault mais justement c'est la que je bloc, dans quoi je les conserves ???

**thibaut** · 17/01/2005, 15h47

Dans un objet en session et tu utilises un SessionListener... Tu stockes tes données de connection à la base (hors user et mot de passe) dans un objet propre a chaque utilisateur...

Au fait c'est thibaut et pas thibault (maise c'est pas grave)

.

**nuke_y** · 17/01/2005, 15h47

Dans un singleton ... En fait tu utilises le mieux du meilleur du plus bien des 2 méthodes. Enfin, je ferais comme ça ...

**thibaut** · 17/01/2005, 15h51

Le problème du singleton est qu'il est propre a un serveur et non à unse session: il est intialisé une fois le serveur ouvert et supprimé quand le serveur est fermé... pas quand la session utilisateur est fermée ...

**brousaille** · 17/01/2005, 15h54

Y a quand meme un truc qui m'echappe , ok je peux faire un singleton, mais l'instance de l'objet qu'il me renvoit il faut bien qu'il aille la chercher.

Et il faut surtout que cette instance est été vivante durant toute la session de l'application ou de l'utilisateur. Donc le getInstance, il va aller la chercher ou l'instance ???

**thibaut** · 17/01/2005, 16h07

Un singleton conserve l'instance de l'objet en mémoire dans une varibale de classe (static)...

**brousaille** · 17/01/2005, 16h28

Merci Thibault,vienna et nuke , je vais essayer ca ce soir !!!!!

**nuke_y** · 17/01/2005, 17h40

je suis d'accord avec toi thibaut, sur le fait que le singleton a la durée de l'instance du serveur et pas de la session, mais pour un objet qui concerne la base de données, n'est-ce pas ce qu'il recherche en fait ? Parce que des paramètres de connection à la base de données qui ne vivent que le temps d'une session ...

**brousaille** · 17/01/2005, 17h46

J'ai pas compris ton intervention nuke ??

**LoulouFifi** · 17/01/2005, 17h55

Pour ma part, j'ai rencontré le meme souci, et j'ai mis en place la solution proposée par Thibaut à savoir, stocker dans la session a l'aide de la classe SessionListener et ca marche nickel...
c'est propre, c'est clair...et t'es sur de tout libérer apres
Voila pour mon avis...

**nuke_y** · 17/01/2005, 17h59

Envoyé par thibaut

Le problème du singleton est qu'il est propre a un serveur et non à unse session: il est intialisé une fois le serveur ouvert et supprimé quand le serveur est fermé... pas quand la session utilisateur est fermée ...

Et je pense que c'est bien ce dont tu as besoin, que ton objet contenant les paramètres de connexion à ta BDD ait la même durée de vie que ton serveur et non pas seulement la durée de vie des sessions.

Exemples :

Durée de vie du serveur :
Tu lances ton serveur, ton singleton va récupérer les paramètres et chaque fois qu'un utilisateur se connecte et que la BDD est solicitée, ton appli crée une connexion à la BDD grâce aux paramètres de ton singleton, récupère les données et ferme la connexion puis libère la mémoire des objets de la connexion.

Durée de vie d'une session utilisateur :
Tu lances ton serveur et c'est tout. chaque fois qu'un utilisateur se connecte et que la BDD est solicitée, ton appli va récupérer les paramètres (accés au disque du serveur, etc.) et crée une connexion à la BDD grâce aux paramètres, récupère les données et ferme la connexion puis libère la mémoire des objets de la connexion ET des paramètres. Ce qui donne une sur-activité disque et mémoire s'il y a beaucoup d'utilisateurs.

**brousaille** · 17/01/2005, 18h00

Envoyé par LoulouFifi

Pour ma part, j'ai rencontré le meme souci, et j'ai mis en place la solution proposée par Thibaut à savoir, stocker dans la session a l'aide de la classe SessionListener et ca marche nickel...
c'est propre, c'est clair...et t'es sur de tout libérer apres
Voila pour mon avis...

oui mais ca implique qu'il faut je me trinballe tout le tps le "context"dans la classe qui doit me retourner un objet Connection

**brousaille** · 17/01/2005, 18h03

Envoyé par nuke_y

Et je pense que c'est bien ce dont tu as besoin, que ton objet contenant les paramètres de connexion à ta BDD ait la même durée de vie que ton serveur et non pas seulement la durée de vie des sessions.

Exemples :

Durée de vie du serveur :
Tu lances ton serveur, ton singleton va récupérer les paramètres et chaque fois qu'un utilisateur se connecte et que la BDD est solicitée, ton appli crée une connexion à la BDD grâce aux paramètres de ton singleton, récupère les données et ferme la connexion puis libère la mémoire des objets de la connexion.

Durée de vie d'une session utilisateur :
Tu lances ton serveur et c'est tout. chaque fois qu'un utilisateur se connecte et que la BDD est solicitée, ton appli va récupérer les paramètres (accés au disque du serveur, etc.) et crée une connexion à la BDD grâce aux paramètres, récupère les données et ferme la connexion puis libère la mémoire des objets de la connexion ET des paramètres. Ce qui donne une sur-activité disque et mémoire s'il y a beaucoup d'utilisateurs.

effectivement 100% d'accord