excalibur-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@d-haven.org>
Subject Re: Session bound components
Date Wed, 26 Jan 2005 14:29:29 GMT
Witoslaw Koczewski wrote:
> Hi,
> what about components, requiring a session object? For example a 
> MailboxComponent for a web application. Every HTTP session needs an own 
> instance of MailboxComponent.
> Is there a design pattern for session bound components in Excalibur?

The ECM and Fortress both have ways of introducing new component
"Lifestyles".  That is new ways of managing when a component is created
and destroyed.  Keep in mind that session bound components are not built
into ECM or Fortress because of the narrow focus of that lifestyle (i.e.
it only is for web applications).

If you have a way to listen for session death, then you can safely build
session bound components to ensure that the components are destroyed
properly.  If you do not have a way of doing that (as in the era when I
was doing servlet programming), then it would be better to take a
different approach.

There are two ways of doing what you want.  The first is to bind a
component to a session as you were wanting to do.  This requires
extra coding and making components specific to that new framework.
The second is to bind the component's data to a session object which
is a clever way of maintaining state per component.  The tradeoff,
of course, is that you need to pass the session object in with every
call to the component.  Also, if you store too much information in
the session it can negatively impact performance.  Keep in mind that
to support failover every object stored in the session must be
serializable--and the larger the amount of information to serialize
the more it can negatively impact scalability of servlet engines like
IBM WebSphere or BEA WebLogic which have sophisticated clustering
options available.

Probably the best approach is to use a "key" object stored in the
session object like an Integer or a java.security.Principle or
something of that nature that is small and easily serialized.  You
can store and retrieve whatever information you need using one
component to manage it, accessing it by the key.  It keeps the
component out of the session which means each instance of the
servlet will have its own unique component managing the same data.
Your app will scale better because it doesn't have to store and
reload the session data in some database or LDAP server (such as
is common in the clustering options in the big servlet engines).


"Programming today is a race between software engineers striving to 
build bigger and better idiot-proof programs, and the Universe trying to 
produce bigger and better idiots. So far, the Universe is winning."
                 - Rich Cook

To unsubscribe, e-mail: user-unsubscribe@excalibur.apache.org
For additional commands, e-mail: user-help@excalibur.apache.org

View raw message