You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/06/10 06:56:14 UTC
[Idea] Component Sessions...
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Excalibur-extensions] Implementation-Version Manifest
Entry
Posted by Peter Donald <pe...@apache.org>.
Applied - tah.
At 12:33 AM 6/10/2002 -0700, you wrote:
>Folks,
>The manifest entry Implementation-Version
>is represented as a Deweydecimal although I guess
>its not mandatory to be one UNLike
>Specification-Version entry.
>(ref:
>http://java.sun.com/j2se/1.3/docs/guide/versioning/spec/VersioningSpecification.html#JARManifestFormat
>)
>
>Patch Attached .
>
>Regards,
>V i n a y
>
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! - Official partner of 2002 FIFA World Cup
>http://fifaworldcup.yahoo.comIndex: Extension.java
>===================================================================
>RCS file:
>/home/cvspublic/jakarta-avalon-excalibur/extension/src/java/org/apache/avalon/excalibur/extension/Extension.java,v
>retrieving revision 1.20
>diff -r1.20 Extension.java
>170c170
>< private DeweyDecimal m_implementationVersion;
>---
> > private String m_implementationVersion;
>353c353
>< final DeweyDecimal implementationVersion =
>extension.getImplementationVersion();
>---
> > final String implementationVersion =
> extension.getImplementationVersion();
>409,423c409,410
><
>< if( null != implementationVersion )
>< {
>< try
>< {
>< m_implementationVersion = new DeweyDecimal(
>implementationVersion );
>< }
>< catch( final NumberFormatException nfe )
>< {
>< final String error = "Bad implementation version format
>'" + implementationVersion +
>< "' in '" + extensionName + "'. (Reason: " + nfe + ")";
>< throw new IllegalArgumentException( error );
>< }
>< }
><
>---
> > m_implementationVersion=implementationVersion;
> >
>495c482
>< public DeweyDecimal getImplementationVersion()
>---
> > public String getImplementationVersion()
>538,548c525
>< // Implementation version must be >= required
>< final DeweyDecimal implementationVersion =
>required.getImplementationVersion();
>< if( null != implementationVersion )
>< {
>< if( null == m_implementationVersion ||
>< !isCompatible( m_implementationVersion,
>implementationVersion ) )
>< {
>< return REQUIRE_IMPLEMENTATION_UPGRADE;
>< }
>< }
><
>---
> >
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Excalibur-extensions] Implementation-Version Manifest
Entry
Posted by Peter Donald <pe...@apache.org>.
Hi,
If someone could apply this that would be fantastic.
I wont get a chance to touch it till sometime next week...
At 12:33 AM 6/10/2002 -0700, you wrote:
>Folks,
>The manifest entry Implementation-Version
>is represented as a Deweydecimal although I guess
>its not mandatory to be one UNLike
>Specification-Version entry.
>(ref:
>http://java.sun.com/j2se/1.3/docs/guide/versioning/spec/VersioningSpecification.html#JARManifestFormat
>)
>
>Patch Attached .
>
>Regards,
>V i n a y
>
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! - Official partner of 2002 FIFA World Cup
>http://fifaworldcup.yahoo.comIndex: Extension.java
>===================================================================
>RCS file:
>/home/cvspublic/jakarta-avalon-excalibur/extension/src/java/org/apache/avalon/excalibur/extension/Extension.java,v
>retrieving revision 1.20
>diff -r1.20 Extension.java
>170c170
>< private DeweyDecimal m_implementationVersion;
>---
> > private String m_implementationVersion;
>353c353
>< final DeweyDecimal implementationVersion =
>extension.getImplementationVersion();
>---
> > final String implementationVersion =
> extension.getImplementationVersion();
>409,423c409,410
><
>< if( null != implementationVersion )
>< {
>< try
>< {
>< m_implementationVersion = new DeweyDecimal(
>implementationVersion );
>< }
>< catch( final NumberFormatException nfe )
>< {
>< final String error = "Bad implementation version format
>'" + implementationVersion +
>< "' in '" + extensionName + "'. (Reason: " + nfe + ")";
>< throw new IllegalArgumentException( error );
>< }
>< }
><
>---
> > m_implementationVersion=implementationVersion;
> >
>495c482
>< public DeweyDecimal getImplementationVersion()
>---
> > public String getImplementationVersion()
>538,548c525
>< // Implementation version must be >= required
>< final DeweyDecimal implementationVersion =
>required.getImplementationVersion();
>< if( null != implementationVersion )
>< {
>< if( null == m_implementationVersion ||
>< !isCompatible( m_implementationVersion,
>implementationVersion ) )
>< {
>< return REQUIRE_IMPLEMENTATION_UPGRADE;
>< }
>< }
><
>---
> >
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Idea] Component Sessions...
Posted by Leo Simons <ls...@multimia.com>.
> > Basically, you need to be able to store a component State
> > (session is a misnomer, I think). In avalon framework, a
> > component State *should* be defined by
> > Configuration+Parameters+Context+ComponentManager+Lifecycle
> > stage, even though this is probably not the case for many
> > components as this is not enforced.
>
> <snip/>
>
> Not what I was talking about.
oh....
> I am referring to a component in its fully active phase. It
> can be used by different clients. However, if the component
> communication requires a certain order on calling methods,
> then we should store enough information with the client (i.e.
> session information) to be able to do its work.
ok. Basically you have a lifecycle extension for some components, where
there is a specific contract detailing which methods can be called in
what order between start() and stop()?
> One example is the Generator component. While I think it should
> be rethought, I can't do anything about it right now. We do
> something along these lines:
>
> generator.setup(...);
> generator.setContentHandler(...);
> generator.execute();
>
> The setup(...) would bind the necessary information (like the
> input stream for the SAX events or request parameters, whatever)
> to the session object. The setContentHandler() would bind the
> contenthandler to the session.
>
> that way, if the component is reassigned because other resolving is
> taking too long, we can safely resume where we left off.
And what you want to do is remove the dependency on the specific order
to enable multi-threaded 'setup'?
And then generalize this mechanism to all of avalon?
Sounds very complex, at little gain in everyday setups (how often does
one use SEDA-like architectures?)
// thread 1:
component.lifecycleMethod1( abitofstate );
// thread 2:
component.lifecycleMethod2 ( abitofstate );
// thread 3:
component.lifecycleMethod3( abitofstate );
// thread 4:
component.doSomeStuff();
where thread 1, 2 and 3 run concurrently so order of calling the methods
can not be defined, and thread 4 has to wait for 1, 2 and 3, and it is
furthermore possible to also have threads 4, 5, 6 and 7 doing the same
as 1, 2, 3 and 4 but for a different request?
Still sounds like a transaction to me?
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Idea] Component Sessions...
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> Basically, you need to be able to store a component State
> (session is a misnomer, I think). In avalon framework, a
> component State *should* be defined by
> Configuration+Parameters+Context+ComponentManager+Lifecycle
> stage, even though this is probably not the case for many
> components as this is not enforced.
<snip/>
Not what I was talking about.
I am referring to a component in its fully active phase. It
can be used by different clients. However, if the component
communication requires a certain order on calling methods,
then we should store enough information with the client (i.e.
session information) to be able to do its work.
One example is the Generator component. While I think it should
be rethought, I can't do anything about it right now. We do
something along these lines:
generator.setup(...);
generator.setContentHandler(...);
generator.execute();
The setup(...) would bind the necessary information (like the
input stream for the SAX events or request parameters, whatever)
to the session object. The setContentHandler() would bind the
contenthandler to the session.
that way, if the component is reassigned because other resolving is
taking too long, we can safely resume where we left off. The
information is no longer stored in the component, but in the session
object. When the execute() is done, the session is cleared or
invalidated.
That is the purpose I was envisioning.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[Excalibur-extensions] Implementation-Version Manifest Entry
Posted by Vinay Chandran <vi...@yahoo.com>.
Folks,
The manifest entry Implementation-Version
is represented as a Deweydecimal although I guess
its not mandatory to be one UNLike
Specification-Version entry.
(ref:
http://java.sun.com/j2se/1.3/docs/guide/versioning/spec/VersioningSpecification.html#JARManifestFormat
)
Patch Attached .
Regards,
V i n a y
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
Re: [Idea] Component Sessions...
Posted by Leo Simons <le...@apache.org>.
Basically, you need to be able to store a component State (session is a
misnomer, I think). In avalon framework, a component State *should* be
defined by Configuration+Parameters+Context+ComponentManager+Lifecycle
stage, even though this is probably not the case for many components as
this is not enforced.
This would look like:
interface State
{
Configuration getConfiguration();
Parameters getParameters();
Context getContext();
ComponentManager getComponentManager();
String getLifecycleStage();
}
class DefaultState implements State
{
private final Configuration m_configuration;
private final Parameters m_parameters;
private final Context m_context;
private final ComponentManager m_cm;
private final String m_lifecycleStage;
DefaultState( Configuration p0, Parameters p1,
Context p2, ComponentManager p3, String p4 )
{
m_configuration = p0;
m_parameters = p1;
m_context = p2;
m_cm = p3;
m_lifecycleStage = p4;
}
/* implement bean methods here */
}
interface SerializableConfiguration
extends Configuration, Serializable {}
interface SerializableContext
extends Context, Serializable {}
// etc etc
class StateContainerUtil
{
Component restoreComponentState( Component p0, State p1 )
{
// do magic
}
}
meta-info: StateEnabled
-----------------------
A component that is marked as StateEnabled can be
serialized/deserialized, activated/passivated using its Configuration
(if Configurable), its Parameters (if Parameterizable), its Context (if
Contextualizable), its ComponentManager (if Composable) and its
lifecycle stage (ie "initialized", "started", "stopped", ...) as the
only necessary information.
Note that this is far from easy as something like this requires a
state-checking container that makes sure that everything put into a
context or cm for a StateEnabled component is serializable. This as
opposed to this:
> SessionEnabled
> {
> Map getSession();
> }
(where Map would have to be serializable)
which puts the responsibility for serialization with the component
rather than the container. I think that adds very little value though;
there's a lot of work for the component developer each and every time.
> Any thoughts or inputs?
there you have 'em. One thing I'll stress is that all this should be
optional to all of framework and (almost) all of excalibur, as making
your components serializable is often a lot of work.
cheers,
- Leo, who once started on what he outlines above but found it too much
work to finish, so ended up with a non-avalon solution
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Idea] Component Sessions...
Posted by Peter Donald <pe...@apache.org>.
At 12:56 AM 6/10/2002 -0400, you wrote:
>Any thoughts or inputs?
Sounds like the notion of Activation / Passivation combined with
persistence mechanisms present in may Application servers.
ie You "activate" object prior to use and then when it is done with for now
you passivate it. ie As things come out of pool they are activated and as
they go back in they are passivated. (Thats taken a little liberty with
explanation but you get the general idea).
For stateful objects in the above frameworks you persist the state prior to
passivating and then reload it prior to coming back alive.
If you are seriously thinking about going down that path I would recomend
you use standard java persistence mechanisms for persisting part.
Before you attempt this I would very veyr very very seriously consider
whether you need it or not.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Idea] Component Sessions...
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
Nice lateral thinking, but way too complex to be of any use
for our end-users (developers) I'm afraid.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>