Yes you got it right.
The reason why it is a bad idea is that potentialy it may take up a lot of
resources (the instances in the container and maybe transaction contexts)
which will not be an issue with statless and no EJB in the servlet session
object.
Regards
Morten Jul Nielsen
----------------------------------------------------------------------
Advisory IT-Specialist, Master of Science in Engineering - Informatics
Mobile e-business Practice
Business Innovation Services, IBM Global Services
Sortemosevej 21 - E1C, DK-3450 Aller�d, Denmark
Phone: + 45 45239517, Mobil : +45 23236116 Fax: +45 45236805
Laurent
Letellier To: "'[EMAIL PROTECTED]'"
<[EMAIL PROTECTED]>
<l.letellier@fr cc:
ontoo.com> Subject: RE: Session Tracking question.
--> Use of EJB
10-08-2001
12:32
Please respond
to soap-user
I am using a statefull sessionBean, and yes the container must have an
instance of that bean for each user connected for all the reasons you
exposed.
However I don't clearly understand in your response why it is a bad idea to
store one in the http session.
I do have an idea extrapolating from what you said: is it that storing a
userid doesn't prevent the container from passivating the bean whereas
storing a reference to it does?
That would be a good reason I agree, please tell me if I got it right.
Thanks again,
Laurent
-----Message d'origine-----
De : Morten J Nielsen [mailto:[EMAIL PROTECTED]]
Envoy� : vendredi 10 ao�t 2001 11:51
� : [EMAIL PROTECTED]
Objet : RE: Session Tracking question. --> Use of EJB
Hi Laurent,
Regarding the out of synch for objects stored in the servlet session, this
is of course only interesting for Entity EJB's.
The problem is related to the transaction scope, if the Entity EJB is
outside the transaction in which it was retrieved then each call will
result in a call to the datasource, where as within the same transaction it
will use the data loaded from the datasource (This is the case for IBM
WebSphere and I also think it is valid for BEA).
The following is valid for IBM WebSphere, I don't know if it is the same
for BEA.
The problem with the SessionBean is that the EJB container contains a pool
of SessionBeans.
For stateless SessionBeans the a free SessionBean is used from the pool for
each method call and when the method has finished the SessionBean is
returned to the pool.
For statefull SessionBeans then SessionBean the is taken from the pool when
created (requested) and first returned to the pool when it is released. So
if you reuse a statefull SessionBean through the servlet session then the
EJB container have to reserve a object for each session. Now assume that
the servlet session has an expiry of one hour and you have a 10000 users an
hour then the EJB container have to have atleasd 10000 instances of the
statefull SessionBean. The idea with statefull SessionBean is not that the
state can be reused over a longer period (it is possible), but it makes it
possible to sequentially call a sessionbean that keeps track of previous
calls. It is possible to resue the transaction across calls to the
statefull SessionBean, and still the statefull SessionBean should only be
keept in a short period of time.
Regards
Morten Jul Nielsen
----------------------------------------------------------------------
Advisory IT-Specialist, Master of Science in Engineering - Informatics
Mobile e-business Practice
Business Innovation Services, IBM Global Services
Sortemosevej 21 - E1C, DK-3450 Aller�d, Denmark
Phone: + 45 45239517, Mobil : +45 23236116 Fax: +45 45236805
