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
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
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
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
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
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
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
vied'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
ouchainages plus complexes.
Durée de vie : tant que l'appel reste dans la web app, détruit dès le
retourau 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
lorsde la montée en charge, avec des centaines de clients connectés (ça ne
serapas 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
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" <vfuchs@hotmail.com> wrote in message
news:c537jm$5p7$1@s1.read.news.oleane.net...
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
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
vied'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
ouchainages plus complexes.
Durée de vie : tant que l'appel reste dans la web app, détruit dès le
retourau 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
lorsde la montée en charge, avec des centaines de clients connectés (ça ne
serapas 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
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.
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.
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.
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
ily a 2~3 semaine.
"Valère viandier" wrote ...Bonjour,
Cette méthode est bonne mais, il est important de connaitre la durée
de
vied'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
outime-out de session )
visibilité : l'utilisateur
Scope request :
Informations à transmettres en paramètres lors des chainages
servlet->jspouchainages plus complexes.
Durée de vie : tant que l'appel reste dans la web app, détruit dès le
retourau client
Visibilité : l'utilisateur
Scope page :
Rarement utilisé dans le cas d'application, sert principalement au
partaged'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
sessiondans 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
etaffiche ses propriétés.
Un collègue m'a fait remarqué que cette méthode était à proscrire, car
lorsde la montée en charge, avec des centaines de clients connectés (ça ne
serapas 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
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" <Farid@somewhere.com> a écrit dans le message de
news:4075247e$0$517$636a15ce@news.free.fr...
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" <vfuchs@hotmail.com> wrote in message
news:c537jm$5p7$1@s1.read.news.oleane.net...
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
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
ily a 2~3 semaine.
"Valère viandier" wrote ...Bonjour,
Cette méthode est bonne mais, il est important de connaitre la durée
de
vied'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
outime-out de session )
visibilité : l'utilisateur
Scope request :
Informations à transmettres en paramètres lors des chainages
servlet->jspouchainages plus complexes.
Durée de vie : tant que l'appel reste dans la web app, détruit dès le
retourau client
Visibilité : l'utilisateur
Scope page :
Rarement utilisé dans le cas d'application, sert principalement au
partaged'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
sessiondans 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
etaffiche ses propriétés.
Un collègue m'a fait remarqué que cette méthode était à proscrire, car
lorsde la montée en charge, avec des centaines de clients connectés (ça ne
serapas 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
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
practicesou 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
ily a 2~3 semaine.
"Valère viandier" wrote ...Bonjour,
Cette méthode est bonne mais, il est important de connaitre la durée
devied'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'utilisateurDurée de vie : la durée de la session de l'utilisation ( fin
explicite
outime-out de session )
visibilité : l'utilisateur
Scope request :
Informations à transmettres en paramètres lors des chainages
servlet->jspouchainages plus complexes.
Durée de vie : tant que l'appel reste dans la web app, détruit dès
le
retourau client
Visibilité : l'utilisateur
Scope page :
Rarement utilisé dans le cas d'application, sert principalement au
partaged'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
sessiondans 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
etaffiche ses propriétés.
Un collègue m'a fait remarqué que cette méthode était à proscrire,
car
lorsde la montée en charge, avec des centaines de clients connectés (ça
ne
serapas 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
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" <vfuchs@hotmail.com> wrote in message
news:c538gn$648$1@s1.read.news.oleane.net...
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" <Farid@somewhere.com> a écrit dans le message de
news:4075247e$0$517$636a15ce@news.free.fr...
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" <vfuchs@hotmail.com> wrote in message
news:c537jm$5p7$1@s1.read.news.oleane.net...
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
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
practicesou 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
ily a 2~3 semaine.
"Valère viandier" wrote ...Bonjour,
Cette méthode est bonne mais, il est important de connaitre la durée
devied'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'utilisateurDurée de vie : la durée de la session de l'utilisation ( fin
explicite
outime-out de session )
visibilité : l'utilisateur
Scope request :
Informations à transmettres en paramètres lors des chainages
servlet->jspouchainages plus complexes.
Durée de vie : tant que l'appel reste dans la web app, détruit dès
le
retourau client
Visibilité : l'utilisateur
Scope page :
Rarement utilisé dans le cas d'application, sert principalement au
partaged'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
sessiondans 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
etaffiche ses propriétés.
Un collègue m'a fait remarqué que cette méthode était à proscrire,
car
lorsde la montée en charge, avec des centaines de clients connectés (ça
ne
serapas 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
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...
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...
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...