[Pass 2] Session object with CM

[Berin Loritsch <bl...@apache.org>]

Here is pass 2 at the session object approach.  It demonstrates that the
Session object is not as difficult to manage as one might think.  It
does
add some (minimal) complexity to the container, but it saves the
component
user and the component writer a lot of headaches.  It also allows the
instance to be pooled, or (better yet) used in a ThreadSafe manner.

Before I listed an interface without fully demonstrating how it would
work:

interface SessionEnabled
{
    Map getSession(); // could be a more formal session object....
}

The important thing is that each component is given their own instance
of a ComponentManager.  The client specific ComponentManager is what
handles the session objects.

The CM would work something like this:

class SessionEnabledCM implements ComponentManager
{
    Map m_sessions;
    Map m_proxies;

    // other methods ignored for clarity
    Object lookup(String role)
    {
        Object component = m_proxies.get(role);
        if ( null == component )
        {
            component = Container.createProxy(role);
            m_proxies.put( role, component );
        }

        return component;
    }

    // ....

    Map getSession(String role)
    {
        Map session = (Map)m_sessions.get(role);

        if ( null == session )
        {
             session = new HashMap();
             m_sessions.put( role, session );
        }

        return session;
    }
}


The createProxy() creates the wrapper--it can be a static method,
whatever.
The important thing is that the proxy adds this to the component:

class ProxyComponent implements SessionEnabled // ... Its dynamic....
{
    SessionEnabledCM m_parent;

    Map getSession()
    {
        return m_parent.getSession( role );
    }
}


This can be further speed up by using the Class of the interface instead
of the string representation because we don't have classloader issues
at this level.

The component itself would do something like this:

class MyComponent implements SessionEnabled, YinYang
{
    String yin( String value )
    {
        Map session = getSession();

        // do all sorts of things and store important
        // info in the session for later use

        return (String) session.get("answer");
    }

    String yang( String value )
    {
        Map session = getSession();

        // do all sorts of things and store important
        // info in the session for later use

        return (String) session.get("question");
    }
}


There are a couple of details to work out, but there is no reason why
the
YinYang component can't be either freely shared between all threads of
execution, or freely reclaimed by the container.
--

"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: [Pass 2] Session object with CM

[Leo Sutic <le...@inspireinfrastructure.com>]

> From: Berin Loritsch [mailto:bloritsch@apache.org] 
> 
> > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> > 
> > > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > >
> > > There are a couple of details to work out, but there is no reason 
> > > why the YinYang component can't be either freely shared 
> between all 
> > > threads of execution, or freely reclaimed by the container.
> > 
> > Agreed - none.
> > 
> > Only objection being that enforcing that programming style
> > seems like a headshot to Avalon usability and thus acceptance.
> 
> What do you mean usability/acceptance?  I don't see it that 
> way. Could you expound?

A lot of put() and get(). I mean, just having people implement
a Component interface was too much. Making them comply with this...
 
> > I also think that a PerThread (or a PerClient) handling policy is
> > equivalent to what you have done - with the mapping of role -> 
> > session, you can only have one session per role per client. 
> > If this is not the case, then what are the differences 
> > between PerThread and your proposal?
> 
> There is a difference in a PerThread vs. a PerClient handling 
> policy.  There can be more clients than threads.  The Session 
> is associated with each client.

Got it.
  
> > If you try to expand this - so each client can have 
> lookup() multiple
> > instances of the same role - you end up pooling the sessions.
> 
> That is a different problem altogether.  The session is 
> associated with a role.  If your system requires multiple 
> component instances, that is an agreement that has to be made 
> between the container and the client.

Yep - and then we have either a constraint put on composers
(can't look up the same component twice), or we're back to
square one - except we're pooling sessions instead.
 
> > I also think that most people will end up with all the logic in
> > a single object they put in the session, and just use the component 
> > as a way of extracting that object from the session and invoke a 
> > method on it.
> 
> Really?  Is that what you do with Servlet sessions?

No.
 
> In either case, is that necessarily wrong?

Don't know.

It was a doom & gloom prediction. I would consider and architecture that
results in that being the easiest way out somewhat flawed. Yes, I do not
consider the servlet architecture ideal, but that's neither here nor
there.

/LS


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [Pass 2] Session object with CM

[Berin Loritsch <bl...@apache.org>]

> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com] 
> 
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> >
> > There are a couple of details to work out, but there is no
> > reason why the YinYang component can't be either freely 
> > shared between all threads of execution, or freely reclaimed 
> > by the container.
> 
> Agreed - none.
> 
> Only objection being that enforcing that programming style 
> seems like a headshot to Avalon usability and thus acceptance.

What do you mean usability/acceptance?  I don't see it that way.
Could you expound?


> I also think that a PerThread (or a PerClient) handling policy is 
> equivalent to what you have done - with the mapping of role -> 
> session, you can only have one session per role per client. 
> If this is not the case, then what are the differences 
> between PerThread and your proposal?

There is a difference in a PerThread vs. a PerClient handling
policy.  There can be more clients than threads.  The Session is
associated
with each client.


> If you try to expand this - so each client can have lookup() multiple 
> instances of the same role - you end up pooling the sessions.

That is a different problem altogether.  The session is associated with
a role.  If your system requires multiple component instances, that is
an agreement that has to be made between the container and the client.

The example of this of course is Cocoon's Transformer role.  However,
if the actual instance of the XMLPipeline (the real byproduct of a
transformer)
is returned instead of a new component instance for each type of
transformer
then you have a much cleaner architecture.


> I also think that most people will end up with all the logic in 
> a single object they put in the session, and just use the component 
> as a way of extracting that object from the session and invoke a 
> method on it.

Really?  Is that what you do with Servlet sessions?

In either case, is that necessarily wrong?


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [Pass 2] Session object with CM

[Leo Sutic <le...@inspireinfrastructure.com>]

> From: Berin Loritsch [mailto:bloritsch@apache.org] 
>
> There are a couple of details to work out, but there is no 
> reason why the YinYang component can't be either freely 
> shared between all threads of execution, or freely reclaimed 
> by the container.

Agreed - none.

Only objection being that enforcing that programming style seems
like a headshot to Avalon usability and thus acceptance.

I also think that a PerThread (or a PerClient) handling policy is 
equivalent to what you have done - with the mapping of role -> 
session, you can only have one session per role per client. If this
is not the case, then what are the differences between PerThread and
your proposal?

If you try to expand this - so each client can have lookup() multiple 
instances of the same role - you end up pooling the sessions.

I also think that most people will end up with all the logic in 
a single object they put in the session, and just use the component 
as a way of extracting that object from the session and invoke a 
method on it.

/LS


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>