[RT] Revisiting Component Access

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

Peter had identified some possibilities for managing components based on
their access point.  He introduced the concept of a "Partition", which
is new terminology and I don't have the full picture on what he means
by it.  Here is my take on Avalon blessed access granularity:

Per-Lookup -- You get a unique component instance for each lookup.
               That unique component can be generated every time, or
               backed by a component pool.  To fully express the
               difference, we need two attributes (i.e. avalon:access=
               per-lookup and avalon:reusable=true).

Per-Thread -- You get a unique component instance for each thread
               of execution.  You will always receive the same component
               no matter where you ask for it in the same Thread.  To
               fully express this arrangement, we only need one attribute
               (i.e. avalon:access=per-thread).

Per-Container -- You get a unique component instance for each container.
                  Any time you ask the component from the container you
                  get the same component (i.e. like ThreadSafe now).  We
                  only need one attribute to express this (i.e.
                  avalon:access=per-container).

Those are the current access policies that we have.  Now we have
identified three other policies that would be helpful in some
situations.  Those policies are application specific:

Per-Transaction -- You have a unique component per transaction, much
                    like a new component instance for each HTTP Request.

Per-Session -- You have the same component for each session.  A session
                is a long running context that may span several
                transactions.

Per-Partition -- You have a unique component instance for each
                  partition.  Partition is left in an undefined state
                  right now.  The focus of this RT is on this piece
                  here.

Both "Per-Transaction" and "Per-Session" require some artifact to be
shared with the client and the container so that the container can
know the context.  The only way arround that is to have the request
and session be passed along to the container from a parent container.
It isn't clean, so we have to examine this later.

 From what I can gather from Peter's comments, per partition is a way
of flattening the container hierarchy, and having one container service
several portions of an application.  In this arrangement, there is one
container, and several partitions.  We would be able to isolate the
various partitions as much as possible.  However, the exact same thing
can be done with sub-containers supporting the various partitions.
I have to wonder which is the better approach.  I am sure we will have
some great discussion on this point.  But there is something better
below:

What if we add a new concept of whether a component is "Inheritable"
accross container boundaries?  What I mean by inheritable is that by
virtue of the way the ComponentManager/ServiceManager works, it will
ask a parent XXXManager for the component if the present one cannot
find it.  By default, all components are inheritable.  That would mean
that if I have a component in the root container, it is accessible
by all sub containers.  The component's access is "inherited" accross
container boundaries.  I can come up with some instances where I don't
want a particular component accessible in a sub-container.  For that
component I want to turn off its "inheritance".

If I define the term "Partition" to be local to a current container,
and not accessible outside that container, then we have a way of doing
that.  The only problem with that is that we have to consider if we need
to combine that functionality with Per-Thread or Per-Lookup.  For that
purpose, the inheritance attribute needs to be separate (i.e.
avalon:inheritable=false).  Currently we need three attributes to fully
express a component's lifestyle:

Action               |  Access            |  Sharable  |  Inheritable**
---------------------+--------------------+------------+---------------
Create new instance  |  Per-Lookup        |      N     |       *
for each request     |                    |            |
---------------------+--------------------+------------+---------------
Use instance from    |  Per-Lookup        |      Y     |       *
pool for each request|                    |            |
---------------------+--------------------+------------+---------------
Create new instance  |  Per-Thread        |      Y*    |       *
for each thread      |                    |            |
---------------------+--------------------+------------+---------------
Create new instance  |  Per-Container     |      Y*    |       *
for each container   |                    |            |
---------------------+--------------------+------------+---------------

* Defaults to "Yes"
** If it is "No" than the component is not accessible outside the scope
    of the current 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>