The EJB stateful session model should be close to (3) below. The Container
can use the ejbPassivate/ejbActivate mechanism to swap out an instance's state
out of memory between the client's transactions.
You can also achieve the same scalability as (3) with Entities. For example, you
can create a bean with container-managed persistence that holds the state of a
client's conversation with the server, such as the content of a shopping cart. The
container has a lot freedom to implement efficient save/restore of the instance's state
in some highly optimized TP monitor provided secondary storage.
Vlada
----- Original Message -----
From: Jorgen Thelin <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, May 22, 1999 4:02 PM
Subject: Re: EJB and Scalability
> >The question really is whether the transient state is on the client or
> >the server.
>
> May I suggest there are actually THREE possibilities here, looking at it
> from a pure architectural viewpoint?
> (1) Stateless component + Stateful client
> =====================================
> Keep the transient state on the client, and send it across the wire with
> each request [basically the MTS approach or EJB State-LESS Session
> Beans]
> (2) Stateful component
> ==================
> Keep the transient state in the server COMPONENT [the EJB State-FUL
> Session Bean approach]
> (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.
>
> This latter option enables HUGE scaleability, as individual server
> component instances are not locked into only handing just one session at
> once [which is the main claim-to-fame for MTS, according to my reading
> of Roger Sessions' Object Watch papers], yet does not require the
> session info to be sent on the wire each time [the major draw back of
> the MTS approach, IMHO]
>
> This approach is how things are done with the "save" area of a server
> component in the old NCR TopEnd transaction processing monitor [now
> bought by out by BEA]. I can testify to the success of the approach as
> I have written a data feed system that was capable of handing
> 300,000,000 transactions per day on a 6x24 basis with great ease and
> positive scaleability - the more work presented, the faster the
> throughput that was achieved, due to the minimised latency of server
> components under heavy loading.
>
> As far as I can see from the EJB spec (even 1.1), their is no way to
> directly implement this "Third Way" without:
> (a) the EJBean instance to have access to a "save area" provided by the
> EJB container - the idea place would be through the SessionContext
> object, of course.
> (b) the EJB container being able to swap the context at a finer grained
> level that the instance created / destroyed points.
>
> I guess what this boils down to is session bean INSTANCES that are re-
> entrant (currently disallowed by 6.11.6 in the 1.1 spec) and are allowed
> to utilise transient state data for the duration of a specific method
> invocation only.
>
> It strikes me this is the finer grained instance pooling control
> promised by much of the new POA Policies stuff from the CORBA world, but
> I believe this level of scaleability is not yet achievable with EJB
> without a lot of "Big Iron" to support the "Stateful component"
> approach.
>
>
> Obviously, the above points only apply to session beans and not to
> entity beans, as the letter are by definition stateful instances!
>
>
> >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 ;-)
>
>
> Hope this perhaps clears the waters, rather than muddies them further!
>
> - 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".
