> (3) Stateless component + Stateful session
> ======================================
> The third possibility is to keep the transient state in the server
> "SESSION" infrastructure somewhere, but for the component / instance to
> retain NO state info at all (i.e. a State-LESS bean INSTANCE).
> The saved session state info is then somehow made available to the
> server component as part of the invocation, and the server
> infrastructure preserves this information between invocations for the
> duration of this session.
If I grok what you are saying about #3, you want a private session per
client that doesn't interfere with other clients, and has the same
"throw it away" at the end of the call transient behavior. Is this
correct?
Assume for the moment that one didn't need a session "cookie", similar
to what http servlets use for session models. In this case, what's the
use of pooling session bean instances? The actual amount of memory
consumed by the reentrant session beans is trivial, as all the real data
is in the private "session" area.
> >Microsoft, of course, would like you to keep it on the client, where
> >they control the market. Sun, of course has the opposite view.
>
> And neither of them want to learn from the ideas of the other ;-)
Human nature.
Hal
___
Casual match in a very dry field
http://www.hellblazer.com
===========================================================================
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".
