Why not store a client ID in the servlet and use it to access a stateful
session bean - which then stores the session data for the client? Each time
a new client comes along, add it to the servlet. If the stateful session
bean timesout, remove it from the servlet.

tim

> -----Original Message-----
> From: Vdaygiri, Subu [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, May 15, 2000 4:09 PM
> To:   [EMAIL PROTECTED]
> Subject:      Re: Servlets & Session Bean
>
> > You may also want to consider storing the some of the
> > client-specific state
> > in the applet itself - just the way we do with client-server
> > applications.
>
> Isn't all this (J2EE) just to get away from that ? :^) Less
> resposibilities
> the client has the better.
>
> > In this case, the servlet can just delegate the request from
> > the applet to
> > the session bean.
>
> How does the servlet just delegate the request from the applet to session
> bean ? Does this allow the conversation between the bean-servlet-applet
> kept
> alive ? Thanks
>
> > creating the bean! In the above case, the servlet is the client.
>
> Agree with that. My only point is that applet's session is much more
> important for the application developer than that of servlet. I do realize
> the servlet is the client of session bean.
>
> > - FYI, the HttpSession is highly dependable - the cookie vs
> > However, the servlet may still maintain a HTTP session for the applet
> > client. In fact, I would consider doing so, as it enhances
> > reusability of
> > the servlet. That's of course, a design decision.
>
> I am trying to explore ways to see if I can make one session bean be
> invoked
> from the applet for an entire session (all ideas appreciated). If not for
> that, then the next best thing appears to be the servlet to use the
> HttpSession. As I am not sure where the servlet will run (web server on a
> different machine or in an application server), I would prefer to have as
> much business logic/workflow in the session/entity beans running within an
> application server.
>
> Thanks,
> Subu
>
> ==========================================================================
> =
> 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".

This e-mail, and any attachment, is confidential. If you have received it in error, 
please delete it from your system, do not use or disclose the information in any way, 
and notify me immediately. The contents of this message may contain personal views 
which are not the views of the BBC, unless specifically stated.

===========================================================================
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".

Reply via email to