Modelling a Session: Tradeoffs 2004-04-05 - By Stefan Frank
Back
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)
|
|
