OVH Cloud OVH Cloud

stockage de beans dans la session

6 réponses
Avatar
Vinz
Bonjour,

Je me pose une question par rapport au stockage de beans dans une session
dans un contexte JSP/Servlets. D'après ce que j'ai compris du MVC, les
servlets font leur boulot, instancient un bean avec le résultat, et
redirigent le cleitn vers une jsp, qui elle même va rechercher le bean et
affiche ses propriétés.
Un collègue m'a fait remarqué que cette méthode était à proscrire, car lors
de la montée en charge, avec des centaines de clients connectés (ça ne sera
pas le cas, mais on ne sait jamais pour de futurs projets), ça demande
beaucoup plus de ressources serveur. Ca ne me parait pas débile comme
remarque, alors j'aurai aimé avoir d'autres avis...

merci

--
Vinz

6 réponses

Avatar
Farid
c'est vrai mais ca depends aussi (et surtout) de comment tu stokes ces
beans.
Voici un message listant les different modes qu'avait poste une personne il
y a 2~3 semaine.

"Valère viandier" wrote ...
Bonjour,
Cette méthode est bonne mais, il est important de connaitre la durée de
vie

d'un objet dans les différents <scopes>
Ils sont au nombre de 4 :

Scope application
Informations à partager entre tous les utilisateurs
Durée de vie : la durée de vie du serveur
Visibilité : tous les uilisateurs

Scope session :
Informations à conserver pour l'ensemble de la session de l'utilisateur
Durée de vie : la durée de la session de l'utilisation ( fin explicite ou
time-out de session )
visibilité : l'utilisateur

Scope request :
Informations à transmettres en paramètres lors des chainages servlet->jsp
ou

chainages plus complexes.
Durée de vie : tant que l'appel reste dans la web app, détruit dès le
retour

au client
Visibilité : l'utilisateur

Scope page :
Rarement utilisé dans le cas d'application, sert principalement au partage
d'information entre JSP et TagLib.
Durée de vie : La page JSP ou le Servlet
Visibilité : l'utilisateur



"Vinz" wrote in message
news:c537jm$5p7$
Bonjour,

Je me pose une question par rapport au stockage de beans dans une session
dans un contexte JSP/Servlets. D'après ce que j'ai compris du MVC, les
servlets font leur boulot, instancient un bean avec le résultat, et
redirigent le cleitn vers une jsp, qui elle même va rechercher le bean et
affiche ses propriétés.
Un collègue m'a fait remarqué que cette méthode était à proscrire, car
lors

de la montée en charge, avec des centaines de clients connectés (ça ne
sera

pas le cas, mais on ne sait jamais pour de futurs projets), ça demande
beaucoup plus de ressources serveur. Ca ne me parait pas débile comme
remarque, alors j'aurai aimé avoir d'autres avis...

merci

--
Vinz




Avatar
Vinz
oui je sais, j'avais participé à ce thread je crois ;-) mais je voulais
savoir si le stockage des beans en session faisait parti des best practices
ou au contraire étaient à proscrire, ou ni l'un ni l'autre.


"Farid" a écrit dans le message de
news:4075247e$0$517$
c'est vrai mais ca depends aussi (et surtout) de comment tu stokes ces
beans.
Voici un message listant les different modes qu'avait poste une personne
il

y a 2~3 semaine.

"Valère viandier" wrote ...
Bonjour,
Cette méthode est bonne mais, il est important de connaitre la durée de
vie

d'un objet dans les différents <scopes>
Ils sont au nombre de 4 :

Scope application
Informations à partager entre tous les utilisateurs
Durée de vie : la durée de vie du serveur
Visibilité : tous les uilisateurs

Scope session :
Informations à conserver pour l'ensemble de la session de l'utilisateur
Durée de vie : la durée de la session de l'utilisation ( fin explicite
ou


time-out de session )
visibilité : l'utilisateur

Scope request :
Informations à transmettres en paramètres lors des chainages
servlet->jsp


ou
chainages plus complexes.
Durée de vie : tant que l'appel reste dans la web app, détruit dès le
retour

au client
Visibilité : l'utilisateur

Scope page :
Rarement utilisé dans le cas d'application, sert principalement au
partage


d'information entre JSP et TagLib.
Durée de vie : La page JSP ou le Servlet
Visibilité : l'utilisateur



"Vinz" wrote in message
news:c537jm$5p7$
Bonjour,

Je me pose une question par rapport au stockage de beans dans une
session


dans un contexte JSP/Servlets. D'après ce que j'ai compris du MVC, les
servlets font leur boulot, instancient un bean avec le résultat, et
redirigent le cleitn vers une jsp, qui elle même va rechercher le bean
et


affiche ses propriétés.
Un collègue m'a fait remarqué que cette méthode était à proscrire, car
lors

de la montée en charge, avec des centaines de clients connectés (ça ne
sera

pas le cas, mais on ne sait jamais pour de futurs projets), ça demande
beaucoup plus de ressources serveur. Ca ne me parait pas débile comme
remarque, alors j'aurai aimé avoir d'autres avis...

merci

--
Vinz








Avatar
Farid
ok. :)

Best pratices: hum... ouais...
Common Pratices: OUI.

c'est dans la logique du MVC.
Le bean (entre autre) correspond au model (M) et doit etre (sauf dans des
cas particulier) accessible par le View (jsp...) et le Controller (servlet)

http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc.html

"Vinz" wrote in message
news:c538gn$648$
oui je sais, j'avais participé à ce thread je crois ;-) mais je voulais
savoir si le stockage des beans en session faisait parti des best
practices

ou au contraire étaient à proscrire, ou ni l'un ni l'autre.



Avatar
Farid
Voici aussi quelque liens interessant et qui parles des best Practice et des
performances:

http://java.sun.com/developer/technicalArticles/javaserverpages/servlets_jsp/
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html#1083750

Farid.

"Vinz" wrote in message
news:c538gn$648$
oui je sais, j'avais participé à ce thread je crois ;-) mais je voulais
savoir si le stockage des beans en session faisait parti des best
practices

ou au contraire étaient à proscrire, ou ni l'un ni l'autre.


"Farid" a écrit dans le message de
news:4075247e$0$517$
c'est vrai mais ca depends aussi (et surtout) de comment tu stokes ces
beans.
Voici un message listant les different modes qu'avait poste une personne
il

y a 2~3 semaine.

"Valère viandier" wrote ...
Bonjour,
Cette méthode est bonne mais, il est important de connaitre la durée
de



vie
d'un objet dans les différents <scopes>
Ils sont au nombre de 4 :

Scope application
Informations à partager entre tous les utilisateurs
Durée de vie : la durée de vie du serveur
Visibilité : tous les uilisateurs

Scope session :
Informations à conserver pour l'ensemble de la session de
l'utilisateur



Durée de vie : la durée de la session de l'utilisation ( fin explicite
ou


time-out de session )
visibilité : l'utilisateur

Scope request :
Informations à transmettres en paramètres lors des chainages
servlet->jsp


ou
chainages plus complexes.
Durée de vie : tant que l'appel reste dans la web app, détruit dès le
retour

au client
Visibilité : l'utilisateur

Scope page :
Rarement utilisé dans le cas d'application, sert principalement au
partage


d'information entre JSP et TagLib.
Durée de vie : La page JSP ou le Servlet
Visibilité : l'utilisateur



"Vinz" wrote in message
news:c537jm$5p7$
Bonjour,

Je me pose une question par rapport au stockage de beans dans une
session


dans un contexte JSP/Servlets. D'après ce que j'ai compris du MVC, les
servlets font leur boulot, instancient un bean avec le résultat, et
redirigent le cleitn vers une jsp, qui elle même va rechercher le bean
et


affiche ses propriétés.
Un collègue m'a fait remarqué que cette méthode était à proscrire, car
lors

de la montée en charge, avec des centaines de clients connectés (ça ne
sera

pas le cas, mais on ne sait jamais pour de futurs projets), ça demande
beaucoup plus de ressources serveur. Ca ne me parait pas débile comme
remarque, alors j'aurai aimé avoir d'autres avis...

merci

--
Vinz












Avatar
Vinz
merci beaucoup pour ces liens !

"Farid" a écrit dans le message de
news:40752f11$0$497$
Voici aussi quelque liens interessant et qui parles des best Practice et
des

performances:


http://java.sun.com/developer/technicalArticles/javaserverpages/servlets_jsp/


http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html#1083750


Farid.

"Vinz" wrote in message
news:c538gn$648$
oui je sais, j'avais participé à ce thread je crois ;-) mais je voulais
savoir si le stockage des beans en session faisait parti des best
practices

ou au contraire étaient à proscrire, ou ni l'un ni l'autre.


"Farid" a écrit dans le message de
news:4075247e$0$517$
c'est vrai mais ca depends aussi (et surtout) de comment tu stokes ces
beans.
Voici un message listant les different modes qu'avait poste une
personne



il
y a 2~3 semaine.

"Valère viandier" wrote ...
Bonjour,
Cette méthode est bonne mais, il est important de connaitre la durée
de



vie
d'un objet dans les différents <scopes>
Ils sont au nombre de 4 :

Scope application
Informations à partager entre tous les utilisateurs
Durée de vie : la durée de vie du serveur
Visibilité : tous les uilisateurs

Scope session :
Informations à conserver pour l'ensemble de la session de
l'utilisateur



Durée de vie : la durée de la session de l'utilisation ( fin
explicite




ou
time-out de session )
visibilité : l'utilisateur

Scope request :
Informations à transmettres en paramètres lors des chainages
servlet->jsp


ou
chainages plus complexes.
Durée de vie : tant que l'appel reste dans la web app, détruit dès
le




retour
au client
Visibilité : l'utilisateur

Scope page :
Rarement utilisé dans le cas d'application, sert principalement au
partage


d'information entre JSP et TagLib.
Durée de vie : La page JSP ou le Servlet
Visibilité : l'utilisateur



"Vinz" wrote in message
news:c537jm$5p7$
Bonjour,

Je me pose une question par rapport au stockage de beans dans une
session


dans un contexte JSP/Servlets. D'après ce que j'ai compris du MVC,
les




servlets font leur boulot, instancient un bean avec le résultat, et
redirigent le cleitn vers une jsp, qui elle même va rechercher le
bean




et
affiche ses propriétés.
Un collègue m'a fait remarqué que cette méthode était à proscrire,
car




lors
de la montée en charge, avec des centaines de clients connectés (ça
ne




sera
pas le cas, mais on ne sait jamais pour de futurs projets), ça
demande




beaucoup plus de ressources serveur. Ca ne me parait pas débile
comme




remarque, alors j'aurai aimé avoir d'autres avis...

merci

--
Vinz
















Avatar
Laurent Nel
Bonjour,

Un collègue m'a fait remarqué que cette méthode était à proscrire, car
lors

de la montée en charge, avec des centaines de clients connectés (ça ne
sera

pas le cas, mais on ne sait jamais pour de futurs projets), ça demande
beaucoup plus de ressources serveur. Ca ne me parait pas débile comme
remarque, alors j'aurai aimé avoir d'autres avis...


Pour résoudre ce pb de charge, il est possible de gérer le contexte
applicatif client à l'aide d'EJB session stateful.
En gros, chaque session HTTP contient un bean qui référence un EJB session
stateful qui lui contient tout le contexte de l'utilisateur.
Le nombre d'instances d'ejb stateful en mémoire est contrôlé par un
mécanisme de cache fourni par le conteneur EJB. Il faut paramétrer ce
mécanisme pour optimiser le fonctionnement selon la charge.
En général, les paramètres sont les suivants:
- taille maximale du cache (ie nb max d'instances en mémoire, les autres
étant "swappées" sur disque)
- timeout d'inactivité.

Laurent
--
Laurent NEL, Gérant

www.leuville.com / Conseil - Ingénierie - Formation
Java - J2EE - UML

Offres d'emploi: http://www.leuville.com/entry_servlet?screenÊrrieres