I have another question that piggybacks on this one. Let's suppose you do
keep the state in an HttpSession, and that your app server knows how to
direct requests to get the HttpSession info regardless of what machine in a
cluster it lives on.
My question is, how do you guarantee security of that information? Suppose
that you have cookieId 222. You go into your cookies and change this
manually to 333. Suppose that the person who *really* had cookieId 333 is
currently logged on to your system, and thus their session is still
valid. This would mean that you would be able to hijack another user's
session. How do you get around this?
Thanks,
Jake
At 09:10 AM 6/6/00 -0400, you wrote:
>Most of the replies to Jim's question seemed to favor HttpSession over a
>Stateful Session Bean (SFSB). In some applications, I also agree that this
>is the best approach. In a simple environment, an HttpSession is held in the
>memory of the web server, therefore it is very fast. In those situations
>when the HttpSession is clustered (either shared or duplicated) or
>persistent, the speed advantages decrease.
>
>Some other respondees propose keeping the state closer to the client for
>speed. This argument begins to fall apart when those clients require access
>to other resources, such as database servers, and more importantly EJB
>servers. If an HttpSession object is holding multiple references to EJB
>handles, you may want to consider a SFSB. Speed and efficiency is achieved
>when the bulk of inter-process communication is reduced. This has little to
>do with where state is maintained.
>
>jim
>
>----- Original Message -----
>From: Jim Archer <[EMAIL PROTECTED]>
> > I am interested in peoples opinions on the relative advantages and
> > disadvantages of servlett sessions and statefull session beans. I have
>read
> > many places that statefull session beans are inefficient, since they
> > instantiate a bean that lives as long as a client does, and there is one
> > per client.
>
>===========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff EJB-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
----------------------------------------------------------------------------------
Jake Reichert email: [EMAIL PROTECTED]
Technical Lead Phone: (415) 876-7500
Allpredict Fax: (240) 250-5593
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
