Modelling a Session: Tradeoffs 2004-04-05 - By Manuel Montoro
Back
If you want your application to scale well for a big number of users
them you will end putting it in a clustered server environment. In this
kind of environment, the biggest issue with session state is to keep it
as small as possible, because it must be replicated among servers in
order to get load-balancing and protection against single server (at
least) failure.
So, my recommendation is to put in the session the least information
as possible, normally "pointers" to data in the database. As "pointers"
I refer to information that can be used to recover the information from
the database.
The next question is "Where to put the (thin) session state?". You can
use HTTP sessions as well as SFSB. My advice is to put it in the
HTTP session and use SLSB.
Kind Regards
On 5 Apr 2004 at 13:32, Stefan Frank wrote:
> Hi,
>
> we are currently in the process of migrating a perl-based legacy
> application to j2ee and I'm currently building up the model for some
> parts of the System: I'm especially re-evaluating the approach to model
> the design for storing session-based Information:
>
> The System consists of Projects, that contain DataSets, that contain
> Experiments.
>
> The Requirement is to have a Session that stores the currently active
> Project, the last opened DataSet and the current Experiment, along with
> various other parameters about the current setup of experiments.
>
> The Legacy-App(a perl-based Webapplication) simply stored all this
> values in the Database&retrieved them with every call.
>
> When we move this to a J2EE-Enviroment, inside the session you basically
> get Properties (either flat, or - if it gets more complex -
> hierarchically grouped): As values for the Properties you can either
> have simple Properties, POJO's or handles on EJB's.
>
> So here are my questions:
>
> a) Modelling this as a Stateful SessionBean is the obvious choice(or do
> you disagree?). A less obvious question is how to persist this Session:
> The approach of the legacy-app was to put everything that can be stored
> in the Session, into the DataBase. As it can easily change, what kind of
> Data can be stored in the Session, you have come up with some generic
> mechanism to save the Properties from the Session inside the DB - and
> thereby restrict yourself on types that can easily be persisted (eg.
> Strings, int, long, etc.), and persist the state manually when the
> Stateful-Session is destroyed OR - which is my question: Every major
> Application-Server-vendor persists the "State" of a Stateful session
> anway: Why not just rely on that, have the Application-Server persist
> the state and restore it. Has anybody used a Stateful-Session-Bean&the
> App-servers serialize/deserialize-Mechanisms for long-term Storage of
> Session-State??!
>
> b) We are using hibernate as persistence-framework: The Reason for this
> was the lack of Flexibility of Entity-Beans. This results in an obvious
> choice on the Object you want to store inside the Session: If you want
> to store the last openend Project in the Session, you just take the POJO
> and store it. Alas, this has some obvious drawbacks: The Object may get
> stale, deleted in the meantime, changed etc. - so instead of storing the
> Object inside the Session, you have to store a handle to the Object. I
> actually thought about switching back to EntityBeans, as this seems to
> be the Design-Rationale, that once led to this "heavy" design. So,
> instead of storing the real, persistent Object inside the Session, one
> has to construct a handle, and a means to reconstruct the Object from
> this handle (which in hibernate's case is just the class-name and a
> primary-key). Then again, I end up with the question: Can I simply have
> the App-Server persist this handle or should I write something on my own?!
>
> Has anyone experiences with that?! And knows how the different
> approaches scale (both in terms of performance and development-time)?
>
> thx in advance
> stf
>
> ====================================================================
> Companion Site: http://www.corej2eepatterns.com
> J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
> List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
********************************************************************************
Manuel Antonio Montoro Navarro
E-mail: mmontoro@(protected)
********************************************************************************
Pensamiento del Dia:
Solo existen dos cosas infinitas, el universo
y la estupidez humana, y no estoy realmente
seguro sobre la primera.
-- Albert Einstein.
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
|
|
