I don't see how http session state is cheaper. At the end of the day you
have to manage the state somewhere.
The only way to move to a stateless server model in this case, is to push
the state out to the client, and marshall it back to the server at each
request.
Have your cake and eat it too? Not a chance!
-Chris.
> -----Original Message-----
> From: Jeff Davidson [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, February 17, 2000 12:05 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Caching data in an stateful session EJB???
>
> I guess I didn't explain this very well in my original post, so I need
> to make a clarification here.
>
> We don't want to share information between client sessions. Each
> client session will have it's own set of data to be cached. This
> is why I was thinking that we'd need stateful session beans. In
> one of the replies, someone mentioned using a Servlet
> and the Session object to associate data with a given client.
> This would appear to be less "expensive" than using the stateful
> session bean approach (I assume), but what other issues would be
> involved with this servlet/Session object approach?
>
> Thanks,
> Jeff
>
> ==========================================================================
> =
> 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".
===========================================================================
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".
