You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <pe...@apache.org> on 2002/09/15 12:13:25 UTC
Component Sharing
Hiya,
I have been trying to figure out the best way to decompose the "lifecycle"
concept. For example we have the idea of lifecycles such as;
a. Poolable
b. Stateless
c. Transient/Factory
d. ThreadLocal
However, each of these lifecycle concepts is not atomic. ie The concepts can
be broken down into smaller "concepts". Most of these lifestyles is made up
of three concepts;
1. Access: The way we handle component creation/access
2. Sharing: How we share "in service" components
3. Release: The way we handle component destruction/release
ie
Poolable;
- Access: Each access retrieves a component from pool or creates one
- Sharing: Each access aquires a unique component (so per-access scope)
- Release: Each release puts component back in pool or destroys it
Stateles;
- Access: Each access retrieves a pre created component
- Sharing: Every access aquires the same component (so per-application scope)
- Release: Each release does nothing
Transient;
- Access: Each access creates a new component
- Sharing: Every access aquires a unique component (so per-access scope)
- Release: Each release destroys component
ThreadLocal;
- Access: Each access aquires component associated with thread
- Sharing: Every access in same thread the same component (per-thread scope)
- Release: Each release does nothing
Ignoring Access/Release for the moment I would like to concentrate on the
notion of Sharing in each lifecycle. So we basically end up with the
following break-down of sharing types.
+ per-application
+ per-thread
+ per-access
And I would also like to add "per-request" or "per-transaction" to model the
concept of "Component Transactions" that we have discussed in the past (also
to cover things like is represented in the proposal directory of framework
CVS.
Essentially what I am asking is, does it seem reasonable to break down the
lifestyle stuff this way? If so is shared a good aspect to concentrate on?
--
Cheers,
Peter Donald
--------------------------------
These aren't the droids you're
looking for. Move along.
--------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Sharing
Posted by Peter Donald <pe...@apache.org>.
On Wed, 18 Sep 2002 02:28, Berin Loritsch wrote:
> Peter Donald wrote:
> > On Tue, 17 Sep 2002 00:10, Berin Loritsch wrote:
> > > > + per-application
> > >
> > > Unless the component is in the root container, that should be
> > > "per-container".
> >
> > Kool - I was thinking of having a "per-partition"but I could not find any
> > examples of it in practice. For sub sitemaps, does Cocoon reuse parents
> > "ThreadSafe" components or recreate its' own?
>
> It uses the Parent ComponentManager pattern set forth in Framework.
> A ComponentManager will check its parent if it cannot resolve the
> component. Now, I have screwed with the ComponentSelector patterns a
> bit in that they also delegate back to the parent. It was the only way
> to have sub sitemaps reuse selector hint mappings.
Right. Thats what I thought which is why I was reluctent to add in
per-partition. I want to see some sort of example of per-partition in use
before we add it is an option.
> > per-access means that everytime you do a lookup() you get a new instance.
> > Where per-request means anyytime you do a lookup in same "Component
> > Transaction" you get the same component.
>
> Ok. So "per-transaction" would be better terminology.
yep.
> The problem with
> the transaction access layer is that it is an application specific
> concept. Not all applications have a concept of a transaction. If we
> consider "per-transaction" we would also have to consider "per-session".
hadn't though of that ... I guess so. Unless we support "nested" transactions
in which case session would just be a long running transaction .... then
again thats a kinda goofy model ;)
> Maybe that is something that needs to be thought out better. Do we want
> to represent application access points to be valid Avalon concepts> If
> so, how do we represent this in code with a generic enough
> implementation? What is more important is how do we determine when each
> of those scopes are finished? Unless we pass in some artifact like a
> Transaction/Context object, we will have no way of knowing in a
> framework level way when we have reached the boundaries of application
> specific access points.
Yep - it ends up being container specific when the transaction scopes are
applied and client code can't control it directly (at least not in container
independent way). Still it would be useful enough in places like Cocoon and
other request based systems that we should at least experiment with it ;)
> > Two things. It means we can "assemble" lifestyle out of more primitive
> > tags. This will make it sooo much easier to extend this in the future.
> > And yes - I have a very practical reason in mind.
> >
> :) I'm curious now.
>
> I guess I have to review all the M$ docs on attribute driven programming?
Naah. This will use that attribute driven programming to provide the metadata
but it is not necessary to look into that. I am not sure if there is any
Interceptor 101 docs about - anyone else? Until then you can probably follow
the link I sent and it should allow give at least a basic idea on the
"invoke" style Interceptors.
> > Those ideas I was trying to figure out in containerkit (and previously in
> > atlantis/camelot) are all WRONG WRONG WRONG. I have seen a very very very
> > nice future and it is when everything is written using interceptors.
>
> They do provide a starting point.
True.
atlantis/camelot went the "framework" approach where you had to extend the
classes to make them useful. This sucked - was too inflexible and too much
work.
containerkit went the "component" approach where you use components are wire
them together. Better than above but still too much damn work and too
inflexible.
The next generation follows the "aspect" approach, allows easy assembly of
containers. Makes it easy to customize your own extentions (Maybe even too
easy) to do what you want to do. And if written well enough will be able to
integrate into existing containers with 0 side-effects.
> The fact that they are "rigid" makes
> it easier for people to grasp what they do. I want to be careful that
> we don't go too far down a path that will cause us issues in maintenance
> and evangelism later. When I have a light bulb go off, I will probably
> support you 100%. We also have to consider what are we going to do
> right now.
It wont be done now but it will be done in next month or two - hopefully that
will be enough to convince you ;)
> > That way you want to extend/change the container then it is simple as
> > 1-2-3, A-B-C. For example if you wanted to write an lifestyle that said
> > "I pool between times 3-5 each day and recreate all other times" that
> > would be near impossible with all the current containers. With this new
> > architecture all you need do is create a new interceptor, update the
> > container config and bang! you are done.
> >
> > Interceptors are the future. For my initial thoughts on them see
>
> You are looking at Interceptors to replace the experimental Extensions?
sorta. Where Extensions "extend" the lifecycle in some way, Interceptors will
*be* the lifecycle. (Or at least the Access/Release chains can be).
Interceptors can also do runtime stuff like log each method call on a
particular service interface or whatever.
--
Cheers,
Peter Donald
----------------------------------------
Why does everyone always overgeneralize?
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Sharing
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Tue, 17 Sep 2002 00:10, Berin Loritsch wrote:
> > > + per-application
> >
> > Unless the component is in the root container, that should be
> > "per-container".
>
> Kool - I was thinking of having a "per-partition"but I could not find any
> examples of it in practice. For sub sitemaps, does Cocoon reuse parents
> "ThreadSafe" components or recreate its' own?
It uses the Parent ComponentManager pattern set forth in Framework.
A ComponentManager will check its parent if it cannot resolve the
component. Now, I have screwed with the ComponentSelector patterns a
bit in that they also delegate back to the parent. It was the only way
to have sub sitemaps reuse selector hint mappings.
> > > + per-thread
> > > + per-access
> > >
> > > And I would also like to add "per-request" or "per-transaction" to model
> > > the concept of "Component Transactions" that we have discussed in the
> > > past (also to cover things like is represented in the proposal directory
> > > of framework CVS.
> >
> > Right. Could you clarify the difference between "per-access" and
> > "per-request"?
>
> per-access means that everytime you do a lookup() you get a new instance.
> Where per-request means anyytime you do a lookup in same "Component
> Transaction" you get the same component.
Ok. So "per-transaction" would be better terminology. The problem with
the transaction access layer is that it is an application specific
concept. Not all applications have a concept of a transaction. If we
consider "per-transaction" we would also have to consider "per-session".
I can think of an "InboxManager" component that would maintain the
current state of a users Inbox--with one instance per session....
Maybe that is something that needs to be thought out better. Do we want
to represent application access points to be valid Avalon concepts> If
so, how do we represent this in code with a generic enough
implementation? What is more important is how do we determine when each
of those scopes are finished? Unless we pass in some artifact like a
Transaction/Context object, we will have no way of knowing in a
framework level way when we have reached the boundaries of application
specific access points.
> > > Essentially what I am asking is, does it seem reasonable to break down
> > > the lifestyle stuff this way? If so is shared a good aspect to
> > > concentrate on?
> >
> > It remains to be seen how we expect to have it work. What problems does
> > it solve?
>
> Two things. It means we can "assemble" lifestyle out of more primitive tags.
> This will make it sooo much easier to extend this in the future. And yes - I
> have a very practical reason in mind.
:) I'm curious now.
I guess I have to review all the M$ docs on attribute driven programming?
> I have been inspired by some comments by Igor over in Phoenix land. Now I
> think ALL of our containers are too primitive, too hard and too inflexible.
> In a year they will all be considered obsolete, archaic remains.
>
> Those ideas I was trying to figure out in containerkit (and previously in
> atlantis/camelot) are all WRONG WRONG WRONG. I have seen a very very very
> nice future and it is when everything is written using interceptors.
They do provide a starting point. The fact that they are "rigid" makes
it easier for people to grasp what they do. I want to be careful that
we don't go too far down a path that will cause us issues in maintenance
and evangelism later. When I have a light bulb go off, I will probably
support you 100%. We also have to consider what are we going to do
right now.
> That way you want to extend/change the container then it is simple as 1-2-3,
> A-B-C. For example if you wanted to write an lifestyle that said "I pool
> between times 3-5 each day and recreate all other times" that would be near
> impossible with all the current containers. With this new architecture all
> you need do is create a new interceptor, update the container config and
> bang! you are done.
>
> Interceptors are the future. For my initial thoughts on them see
You are looking at Interceptors to replace the experimental Extensions?
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12405
I'll take a look at your link in detail.
> However my brain has mutated again. Now I have three sets of interceptor
> chains per container. Access chain, Release Chain and Invoke chain. And
> chains are allowed to invoke sub-chains.
>
> MetaData + Tools + Interceptors are what will bring Avalon from being "nice,
> but an effort to get started" to "nice, when do we start".
:)
> > In the SEDA arena, there will be the concept of "stateless" and
> > "per-thread". The "stateless" stage would use a thread-pool to manage
> > load and provide concurrency. To make certain issues easier to deal
> > with, the "per-thread" stage would have a unique instance, and a
> > unique Source. Events would be split in a load balanced manner, and
> > sent to the proper instance of the component. There wouldn't be any
> > reason for "per-access" models in a SEDA environment.
>
> right - but as I said. Break these concepts down into their atomic parts and
> things start becoming soo much nicer.
Aye, and there's the rub. (to quote Hamlet's soliloquy). What is course
grained enought to be easy to use, yet fine grained enough to be
powerfully flexible.
--
"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: Component Sharing
Posted by Peter Donald <pe...@apache.org>.
On Tue, 17 Sep 2002 09:49, Chad Stansbury wrote:
> > > Right. Could you clarify the difference between "per-access" and
> > > "per-request"?
> >
> > per-access means that everytime you do a lookup() you get a new instance.
> > Where per-request means anyytime you do a lookup in same "Component
> > Transaction" you get the same component.
>
> Wouldn't per-lookup and per-transaction be more meaningful then?
per-transaction makes more sense.
However I would prefer to keep per-access as there are alternative mechanisms
for accessing a component other than through Avalons lookup() mechanisms.
Mainly I am thinking of how we expose components to directy systems ala JNDI
or whatever.
--
Cheers,
Peter Donald
---------------------------------------------------
"Wise men don't need advice. Fools don't take it."
-Benjamin Franklin
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Sharing
Posted by Chad Stansbury <st...@earthlink.net>.
> > Right. Could you clarify the difference between "per-access" and
> > "per-request"?
> per-access means that everytime you do a lookup() you get a new instance.
> Where per-request means anyytime you do a lookup in same "Component
> Transaction" you get the same component.
Wouldn't per-lookup and per-transaction be more meaningful then?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Sharing
Posted by Peter Donald <pe...@apache.org>.
On Tue, 17 Sep 2002 18:26, Nicola Ken Barozzi wrote:
> I have seen interceptors being used, and I also have seen many
> implementations as hacks.
This one wont be ;) It already looks sweet.
> You cannot easily control what happens when you put various layers of
> interception in your calls, and it can lead to lack of control.
Err - interceptors are about giving you very very explicit fine grain control.
I am not sure what you mean by this ...
> The point is: what does interception give us that lifecycle extension
> cannot?
pooling, persistence, security, transactions, auditing, etc. All transparently
and for free. There is a reason that all major enterprise frameworks offer
someway to do just this.
> Lifecycle is the *key* to Avalon use and comprehension, and it has
> remained solid in time, where other features have not always.
exactly.
--
Cheers,
Peter Donald
----------------------------------------
Why does everyone always overgeneralize?
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Sharing
Posted by Peter Donald <pe...@apache.org>.
On Tue, 17 Sep 2002 15:27, Leo Simons wrote:
> Could be nice...my feeling is that in two years, that will again be
> obsolete 'cause everything will be written using SEDA/Silk-like stuff. I
> had the feeling a long time ago when first playing around with the
> Commandable stuff (ie observer/command pattern).
Naah - event driven approaches are an othogonal concept. While neat I doubt
they will ever gain real popularity because of the difficulty of implementing
them properly. The only real gain is for separating app layers and operating
under sustained loads. I think it will gain a little on backend but threaded
high level layered apis (ie Servlet API) are where it's at for 99% of
programmers.
Then again - I may be biased as I spent two years of my life debugging one of
these messes ... errr systems ;)
However that has nothing to do what I am talking about. What I am talking
about is the implementation strategy for adding arbitary aspects to services.
Need persistence? No problem. Need replication, clustering and
synchronization? Doable. Need Instrumentation? Easy. Need to load Avalon
"services" that wrap a web service - piece of piss. Need to persist the
changes from this web service. Not a problem.
--
Cheers,
Peter Donald
----------------------------------------------
Money is how people with no talent keep score.
----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Sharing
Posted by Leo Simons <le...@apache.org>.
On Tue, 2002-09-17 at 14:44, Berin Loritsch wrote:
> Leo Simons wrote:
> >>I have been inspired by some comments by Igor over in Phoenix land. Now I
> >>think ALL of our containers are too primitive, too hard and too inflexible.
> >>In a year they will all be considered obsolete, archaic remains.
> >>
> >>Those ideas I was trying to figure out in containerkit (and previously in
> >>atlantis/camelot) are all WRONG WRONG WRONG. I have seen a very very very
> >>nice future and it is when everything is written using interceptors.
> >
> >
> > Could be nice...my feeling is that in two years, that will again be
> > obsolete 'cause everything will be written using SEDA/Silk-like stuff. I
> > had the feeling a long time ago when first playing around with the
> > Commandable stuff (ie observer/command pattern).
> >
> > We'll see.....
>
>
> Not everything. It is a different component model completely. SEDA
> would not be a good fit for Cocoon because you cannot work on a partial
> document at a time.
=)
My bet is that the things you would solve in cocoon using interceptors
you could better solve with an event model...of course you can't make
everything into events, but you can't make everything into interceptors
either (or you end up in dynamic hell).
> It works best when you can assemble a document
> model piece by piece, or even better process it directly in the stream.
SAX is basically event-based, isn't it =)
it is just that SAX guarantees a certain order to events. (ie precisely
follows the XML file it reads). I can't see why you cannot make
guarantees like that in SEDA-like systems.
oh well, this is distant-future stuff....interceptors have been around a
lot longer =)
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Sharing
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
> Leo Simons wrote:
>
>>> I have been inspired by some comments by Igor over in Phoenix land.
>>> Now I think ALL of our containers are too primitive, too hard and too
>>> inflexible. In a year they will all be considered obsolete, archaic
>>> remains.
>>>
>>> Those ideas I was trying to figure out in containerkit (and
>>> previously in atlantis/camelot) are all WRONG WRONG WRONG. I have
>>> seen a very very very nice future and it is when everything is
>>> written using interceptors.
>>
>>
>>
>> Could be nice...my feeling is that in two years, that will again be
>> obsolete 'cause everything will be written using SEDA/Silk-like stuff. I
>> had the feeling a long time ago when first playing around with the
>> Commandable stuff (ie observer/command pattern).
>>
>> We'll see.....
>
>
>
> Not everything. It is a different component model completely. SEDA
> would not be a good fit for Cocoon because you cannot work on a partial
> document at a time.
Which is the wall I have been hitting with Morphos lately.
SAX pipelines are something you cannot easily preempt, because they
don't have physical phases... unless you work on preempting the parsing
somewhat :-/
> It works best when you can assemble a document
> model piece by piece, or even better process it directly in the stream.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Sharing
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
>>I have been inspired by some comments by Igor over in Phoenix land. Now I
>>think ALL of our containers are too primitive, too hard and too inflexible.
>>In a year they will all be considered obsolete, archaic remains.
>>
>>Those ideas I was trying to figure out in containerkit (and previously in
>>atlantis/camelot) are all WRONG WRONG WRONG. I have seen a very very very
>>nice future and it is when everything is written using interceptors.
>
>
> Could be nice...my feeling is that in two years, that will again be
> obsolete 'cause everything will be written using SEDA/Silk-like stuff. I
> had the feeling a long time ago when first playing around with the
> Commandable stuff (ie observer/command pattern).
>
> We'll see.....
Not everything. It is a different component model completely. SEDA
would not be a good fit for Cocoon because you cannot work on a partial
document at a time. It works best when you can assemble a document
model piece by piece, or even better process it directly in the stream.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Sharing
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
>>I have been inspired by some comments by Igor over in Phoenix land. Now I
>>think ALL of our containers are too primitive, too hard and too inflexible.
>>In a year they will all be considered obsolete, archaic remains.
>>
>>Those ideas I was trying to figure out in containerkit (and previously in
>>atlantis/camelot) are all WRONG WRONG WRONG. I have seen a very very very
>>nice future and it is when everything is written using interceptors.
Interceptors, MVC, Model 12345, etc, buzzwords IMHO.
I have seen interceptors being used, and I also have seen many
implementations as hacks.
You cannot easily control what happens when you put various layers of
interception in your calls, and it can lead to lack of control.
This in general, but maybe you have The Right Way...
> Could be nice...my feeling is that in two years, that will again be
> obsolete 'cause everything will be written using SEDA/Silk-like stuff. I
> had the feeling a long time ago when first playing around with the
> Commandable stuff (ie observer/command pattern).
And I have the same feeling too...
The point is: what does interception give us that lifecycle extension
cannot?
Lifecycle is the *key* to Avalon use and comprehension, and it has
remained solid in time, where other features have not always.
Peter Donald wrote:
"
For example a component C1, may expose services S1 and S2. When a call
is made on S1 from component C2 then Interceptor chain I1 is used, while
if C2 made a call on S2 then chain I2 is used. If another component C3
made a call on S1 then I3 may be used.
As you can see this gets very complex, very fast. Because of this we
need to define a simple, yet sufficiently capable enough configuration
format for these interceptr chains. (If this is even possible).
"
Interceptors are nice conceptually, but must be yet tested in Avalon
with regards to extensions.
> We'll see.....
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Sharing
Posted by Leo Simons <le...@apache.org>.
> I have been inspired by some comments by Igor over in Phoenix land. Now I
> think ALL of our containers are too primitive, too hard and too inflexible.
> In a year they will all be considered obsolete, archaic remains.
>
> Those ideas I was trying to figure out in containerkit (and previously in
> atlantis/camelot) are all WRONG WRONG WRONG. I have seen a very very very
> nice future and it is when everything is written using interceptors.
Could be nice...my feeling is that in two years, that will again be
obsolete 'cause everything will be written using SEDA/Silk-like stuff. I
had the feeling a long time ago when first playing around with the
Commandable stuff (ie observer/command pattern).
We'll see.....
- LSD
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Sharing
Posted by Peter Donald <pe...@apache.org>.
On Tue, 17 Sep 2002 00:10, Berin Loritsch wrote:
> > + per-application
>
> Unless the component is in the root container, that should be
> "per-container".
Kool - I was thinking of having a "per-partition"but I could not find any
examples of it in practice. For sub sitemaps, does Cocoon reuse parents
"ThreadSafe" components or recreate its' own?
> > + per-thread
> > + per-access
> >
> > And I would also like to add "per-request" or "per-transaction" to model
> > the concept of "Component Transactions" that we have discussed in the
> > past (also to cover things like is represented in the proposal directory
> > of framework CVS.
>
> Right. Could you clarify the difference between "per-access" and
> "per-request"?
per-access means that everytime you do a lookup() you get a new instance.
Where per-request means anyytime you do a lookup in same "Component
Transaction" you get the same component.
> > Essentially what I am asking is, does it seem reasonable to break down
> > the lifestyle stuff this way? If so is shared a good aspect to
> > concentrate on?
>
> It remains to be seen how we expect to have it work. What problems does
> it solve?
Two things. It means we can "assemble" lifestyle out of more primitive tags.
This will make it sooo much easier to extend this in the future. And yes - I
have a very practical reason in mind.
I have been inspired by some comments by Igor over in Phoenix land. Now I
think ALL of our containers are too primitive, too hard and too inflexible.
In a year they will all be considered obsolete, archaic remains.
Those ideas I was trying to figure out in containerkit (and previously in
atlantis/camelot) are all WRONG WRONG WRONG. I have seen a very very very
nice future and it is when everything is written using interceptors.
That way you want to extend/change the container then it is simple as 1-2-3,
A-B-C. For example if you wanted to write an lifestyle that said "I pool
between times 3-5 each day and recreate all other times" that would be near
impossible with all the current containers. With this new architecture all
you need do is create a new interceptor, update the container config and
bang! you are done.
Interceptors are the future. For my initial thoughts on them see
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12405
However my brain has mutated again. Now I have three sets of interceptor
chains per container. Access chain, Release Chain and Invoke chain. And
chains are allowed to invoke sub-chains.
MetaData + Tools + Interceptors are what will bring Avalon from being "nice,
but an effort to get started" to "nice, when do we start".
> In the SEDA arena, there will be the concept of "stateless" and
> "per-thread". The "stateless" stage would use a thread-pool to manage
> load and provide concurrency. To make certain issues easier to deal
> with, the "per-thread" stage would have a unique instance, and a
> unique Source. Events would be split in a load balanced manner, and
> sent to the proper instance of the component. There wouldn't be any
> reason for "per-access" models in a SEDA environment.
right - but as I said. Break these concepts down into their atomic parts and
things start becoming soo much nicer.
arg ... and now I am late for work ... :L
--
Cheers,
Peter Donald
-----------------------------------------------------------
Don't take life too seriously --
you'll never get out of it alive.
-----------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Sharing
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> Hiya,
>
> I have been trying to figure out the best way to decompose the "lifecycle"
> concept. For example we have the idea of lifecycles such as;
> a. Poolable
> b. Stateless
> c. Transient/Factory
> d. ThreadLocal
>
> However, each of these lifecycle concepts is not atomic. ie The concepts can
> be broken down into smaller "concepts". Most of these lifestyles is made up
> of three concepts;
> 1. Access: The way we handle component creation/access
> 2. Sharing: How we share "in service" components
> 3. Release: The way we handle component destruction/release
>
> ie
Currently, you should think of Poolable and Transient as specializations
of each other. Whichever way you look at it as the root version.
<snip/>
> + per-application
Unless the component is in the root container, that should be
"per-container".
> + per-thread
> + per-access
>
> And I would also like to add "per-request" or "per-transaction" to model the
> concept of "Component Transactions" that we have discussed in the past (also
> to cover things like is represented in the proposal directory of framework
> CVS.
Right. Could you clarify the difference between "per-access" and
"per-request"?
Unless you are speaking in an App Specific manner like a per HTTP
request....
>
> Essentially what I am asking is, does it seem reasonable to break down the
> lifestyle stuff this way? If so is shared a good aspect to concentrate on?
It remains to be seen how we expect to have it work. What problems does
it solve?
In the SEDA arena, there will be the concept of "stateless" and
"per-thread". The "stateless" stage would use a thread-pool to manage
load and provide concurrency. To make certain issues easier to deal
with, the "per-thread" stage would have a unique instance, and a
unique Source. Events would be split in a load balanced manner, and
sent to the proper instance of the component. There wouldn't be any
reason for "per-access" models in a SEDA environment.
So the bottom line lies in what issues you want to solve.
--
"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>