What Jorgen calls the "session key" is the Session EJB Object's identifier that the
container
creates at Session EJB Object's creation time and stores in the object reference.
----- Original Message -----
From: Jorgen Thelin <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, May 23, 1999 12:18 AM
Subject: Re: EJB and Scalability
> >> (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".
>
>
===========================================================================
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".
