First, let me state the problem.
We have identified several creational patterns that we believe should
work
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
information
internally while the complete request is being processed. Sort of the
way things work in blocking web servers. A request is handled by a
thread
until it is done.
With the advent of non-blocking code and asynchronous component
topologies
like SEDA, we cannot any longer assume that one thread operates on the
same
component for its life.
Also, if we were to introduce an automatic reclamation of pooled
components,
we would need a way to store state information to the component. That
way
the component can be pulled back and reused by another thread of
execution,
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
"method"
calls are the URIs and data passed back and forth with the client
browser.
If a servlet needs to maintain information between each "method" call
then
it stores the necessary information in a Session object.
The purpose of the Session object would be to restore the Component to
the
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
be
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
workings
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
would
allow access to the session.
The Servlet spec has a Request object, a Response object, a Context
object,
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.
Perhaps,
the best appraoch is to define an interface like this:
SessionEnabled
{
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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
