avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject [Idea] Component Sessions...
Date Mon, 10 Jun 2002 04:56:14 GMT
First, let me state the problem.

We have identified several creational patterns that we believe should
with our components.  We are aware that we cannot make all components
threadsafe.  One solution is to make the component exist in each thread,
possibly with a thread-local variable or something.  The assumption is
that the component would be able to maintain state and session
internally while the complete request is being processed.  Sort of the
way things work in blocking web servers.  A request is handled by a
until it is done.

With the advent of non-blocking code and asynchronous component
like SEDA, we cannot any longer assume that one thread operates on the
component for its life.

Also, if we were to introduce an automatic reclamation of pooled
we would need a way to store state information to the component.  That
the component can be pulled back and reused by another thread of
and then pick up where it left off before it was reclaimed.

The concept works very much like the Session object in the Servlet spec.
In a way, you can think of a Servlet as a type of component who's
calls are the URIs and data passed back and forth with the client
If a servlet needs to maintain information between each "method" call
it stores the necessary information in a Session object.

The purpose of the Session object would be to restore the Component to
last state it was in before it was reclaimed.  It is not meant to hold
a lot of data (same with the Servlet spec).  This session object would
at heart just a Map or something similar.  The only unique thing is that
the session state information would be maintained with the client, not
the component.  Furthermore, the client should have no knowledge of its
existence--just like the user of a web application does not see the
of the session object in their browser.

We would either have to give the session object to the component as part
of its lifecycle, or we would have to create a special Context that
allow access to the session.

The Servlet spec has a Request object, a Response object, a Context
and the Session object.  The context object is given at initialization,
and it remains constant for the life of the servlet.  The request object
provides the request information and the Session object.  Finally, the
response object sends everything back.

In the micro, this is really too much work.  All we are interested in is
the Session object--and that is only for components that need it.
the best appraoch is to define an interface like this:

    Map getSession();

That would allow the container to provide a proxy to supply the session
object, or something along those lines.

The difference between getSession() and setSession() is one of design.
A component should operate without the *express* knowledge that it is
pooled, but the session object lets it opperate safely that way.  If we
implemented it as a setSession(), it would require the proxy to set the
session each time, and the component to react to multiple calls on it.
I have a feeling it would be a better design all the way around if the
session object were available on demand.

Any thoughts or inputs?


"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
                - Benjamin Franklin

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message