>> (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?
I think we are talking about the same thing:
One session-per-client but without having to tie that up to one
instance-per-session.
As Vlada Matena points out in another mail, this can be done in the
current EJB architecture by using an Entity bean to hold the "session
state" between calls.
It does require the client to supply an extra parameter of a "session
key" value on each call :-( , but it is definitely achievable now.
I am still undecided in my mind whether there is then much difference in
resource usage between passivated stateful session beans and stateless
session beans with stored entity beans, but I guess a few proper
"prototype projects" will give us the answer to this!
It is probably amusing (to me at least!) to realise that this is
actually the way Microsoft recommends writing MTS components to keep
them stateless (!), except of course they store the state info in the
database and hence won't get any caching effect that a reasonable EJB
container will perform for a recently used Entity bean.
I guess the cross fertilisation of ideas between Sun and Microsoft does
happen after all!
>Assume for the moment that one didn't need a session "cookie", similar
>to what http servlets use for session models.
But I think one does! The client (or client-side stubs?) needs to send
some sort of "session key" so the session info can be retrieved. I
don't think there is any way to get this info from the container session
infrastructure - and if the EJBean is marked as stateless, it probably
isn't even stored anywhere.
> In this case, what's the
>use of pooling session bean instances?
Just pure concurrency.
The above can be done with the current EJB spec, without needing to go
to re-entrant session bean instances (not allowed at EJB 1.x), while
still being able to handle requests from multiple client sessions
simultaneously.
I guess I'll never stop having to learning new tricks! ;-)
- Jorgen
------------------------------------------------------------
| Software Technologies -=-=:=-=- http://www.swtech.com/ |
| -----------> One-stop Developer Reference <----------- |
| Technical reference for professional software developers |
------------------------------------------------------------
===========================================================================
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".
