>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".
