Manuel Montoro wrote:
> 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.
agreed - but does this solve my problem of persisting the Session?!
Write some handwritten Persister's or use the App-server? And if i can't
make it small (e.g. lots of Strings used to configure the Session) -
should I then store only a handle on the Configuration and store the
actual configuration in the DB (that means: replicating only the handle,
not the Data)

>
> 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.
We'll have to support different clients - not all of them will connect
using http (unless we force them to): What is the compelling reason to
use a http-session instead of a S*F*SB?!
>
> 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)
>

====================================================================
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)