You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Torsten Curdt <tc...@dff.st> on 2002/02/21 13:10:28 UTC
ComponentManager and sessions
I need to place an Object into a user's HttpSession. Usually I would
make this Object a recyclable component but I am a bit scared...
1.) this object is only poolable and recyclable - not threadsafe
This means if someone would create thousands of sessions could
harm the ComponentManager.
2.) someone could timeout the session and the component might not get
released.
Although I could use a HttpSessionBindingListener to release to
component I don't really feel very good with this mechanism.
BTW: is it possible to set the pool size to unlimitted at all?
I'd really make it a component because of the easy of configuration and
"plugin" like behaviour. A component that does not have to be released
would be cool for this. (following the last discussions I'd like to add:
I'm not quite if this really reasonable for all components because this
would be like implementing an additional GC in java) A "newInstance"
method in the ComponentManager would be sufficient for my case. So those
components could share the same configuation facilities but are not handle
inside the CM.
Can someone please comment on this?
Thanks
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentManager and sessions
Posted by Peter Royal <pr...@managingpartners.com>.
On Thursday 21 February 2002 02:00 pm, Torsten Curdt wrote:
> Thanks, Pete.
no prob.
> One last question: How big is a pool when not explicitly specified?
min 2 max 8
see org.apache.avalon.excalibur.component.PoolableComponentHandler
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentManager and sessions
Posted by Torsten Curdt <tc...@dff.st>.
On Thu, 21 Feb 2002, Peter Royal wrote:
> On Thursday 21 February 2002 10:26 am, Torsten Curdt wrote:
> > > Isn't this basically a SingleThreaded component? Where every time one is
> > > requested from the CM a new instance is created?
> >
> > Yes... seems you are right. But do I have to release it?
>
> Not really :) When you release a SingleThreaded component, it will only call
> stop() and dispose() if the component is Startable and Disposable
> respectively.
ok
> Since you wrote your component, as long as it doesn't lock onto any resources
> for its entire lifespan you could get away with not releasing it at all.
I feer this could happen :(
> Otherwise if it is holding onto something that should be released, (or for
> completeness) you could implement a HttpSessionListener (or whatever the name
> was...) and just have it check for Startable and Disposable and call if
> needed.
Hm... ok
> Personally, I'd just stick it in the session, make sure I don't latch onto
> any poolable resources for the life of my component :)
Thanks, Pete.
Seems like I really have to use the HttpSessionListener then :-/
One last question: How big is a pool when not explicitly specified?
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ComponentManager and sessions
Posted by Stephen McConnell <mc...@apache.org>.
Torsten Curdt wrote:
>
> > Just for reference, in our platform when an client is requesting a
> > pooled service it *always* narrows this to a particular type
> > (typically a factory object) and handles access and decommissioning
> > against a specific type based on its own lifecycle requirements
> > for the object in question. This may be for the duration of a single
> > invocation but more typically, the supplied factory will handle
> > caching of the supplied instance for a configured period of time - i.e.
> > overriding any request from the client to release the instance because
> > the factory knows more about the real world and the factory client only
> > just knows about doing its job.
>
> Maybe I'm too tired yet but...
> Sorry - I'm not quite getting what you are trying to say with that...
> ...could please explain a bit more?
Torsten:
Here is a more detailed explanation of the above - based on our own
experience of handling managers, factories, services etc.
First of all let me declare that I'm opposed to the introduction of
implied semantics on Object - and for this reason, our implementations
make the notion of release explicit on the object that is provided
by lookup. If an object must be released, this is a behaviour that
should be applied to the object being released. It is then up to that
object implementation to notify its manager (or container) of the
release.
In our environment an object supplied by a manager is typically one
of the following three:
1. a service implementation
- handles request from the client to do something
- typically exists for the life of the manager
- is typically created and disposed of by the manager
2. a factory implementation
- handles the creation of new instances of something
- factory is typically created by and disposed of by the
manager
- may have a caching policy which overrides the client
decision to release (for example, an object provided by
the factory may be "Releasable", the release
implementation notifies the factory of the release -
the factory is then free reallocate the object on the
pool or take any other action based on its own caching
policy)
- pooled objects in the above example are not constrained
to be single or multi-threaded (that's an implementation
decision that IMO should not be exposed in an interface)
3. a dynamic manager
- handles lookup requests for dynamically created services
- typically exists for the lifetime of the manager
- lookup requests are non-predictable because the services
it can provides are dynamically generated based on:
a) static configuration using DPML (digital product
modelling language service descriptions)
b) DPML meta-models published to the manager during
its lifetime
- will typically provide change listener and event support
Hope that helps.
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ComponentManager and sessions
Posted by Torsten Curdt <tc...@dff.st>.
> Just for reference, in our platform when an client is requesting a
> pooled service it *always* narrows this to a particular type
> (typically a factory object) and handles access and decommissioning
> against a specific type based on its own lifecycle requirements
> for the object in question. This may be for the duration of a single
> invocation but more typically, the supplied factory will handle
> caching of the supplied instance for a configured period of time - i.e.
> overriding any request from the client to release the instance because
> the factory knows more about the real world and the factory client only
> just knows about doing its job.
Maybe I'm too tired yet but...
Sorry - I'm not quite getting what you are trying to say with that...
...could please explain a bit more?
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ComponentManager and sessions
Posted by Stephen McConnell <mc...@apache.org>.
Just for reference, in our platform when an client is requesting a
pooled service it *always* narrows this to a particular type
(typically a factory object) and handles access and decommissioning
against a specific type based on its own lifecycle requirements
for the object in question. This may be for the duration of a single
invocation but more typically, the supplied factory will handle
caching of the supplied instance for a configured period of time - i.e.
overriding any request from the client to release the instance because
the factory knows more about the real world and the factory client only
just knows about doing its job.
Cheers, Steve.
> -----Original Message-----
> From: Peter Royal [mailto:proyal@managingpartners.com]
> Sent: Thursday, 21 February, 2002 16:32
> To: Avalon Developers List
> Subject: Re: ComponentManager and sessions
>
>
> On Thursday 21 February 2002 10:26 am, Torsten Curdt wrote:
> > > Isn't this basically a SingleThreaded component? Where every
> time one is
> > > requested from the CM a new instance is created?
> >
> > Yes... seems you are right. But do I have to release it?
>
> Not really :) When you release a SingleThreaded component, it
> will only call
> stop() and dispose() if the component is Startable and Disposable
> respectively.
>
> Since you wrote your component, as long as it doesn't lock onto
> any resources
> for its entire lifespan you could get away with not releasing it at all.
> Otherwise if it is holding onto something that should be
> released, (or for
> completeness) you could implement a HttpSessionListener (or
> whatever the name
> was...) and just have it check for Startable and Disposable and call if
> needed.
>
> Personally, I'd just stick it in the session, make sure I don't
> latch onto
> any poolable resources for the life of my component :)
> -pete
>
> --
> peter royal -> proyal@managingpartners.com
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentManager and sessions
Posted by Peter Royal <pr...@managingpartners.com>.
On Thursday 21 February 2002 10:26 am, Torsten Curdt wrote:
> > Isn't this basically a SingleThreaded component? Where every time one is
> > requested from the CM a new instance is created?
>
> Yes... seems you are right. But do I have to release it?
Not really :) When you release a SingleThreaded component, it will only call
stop() and dispose() if the component is Startable and Disposable
respectively.
Since you wrote your component, as long as it doesn't lock onto any resources
for its entire lifespan you could get away with not releasing it at all.
Otherwise if it is holding onto something that should be released, (or for
completeness) you could implement a HttpSessionListener (or whatever the name
was...) and just have it check for Startable and Disposable and call if
needed.
Personally, I'd just stick it in the session, make sure I don't latch onto
any poolable resources for the life of my component :)
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentManager and sessions
Posted by Torsten Curdt <tc...@dff.st>.
On Thu, 21 Feb 2002, Peter Royal wrote:
> On Thursday 21 February 2002 07:10 am, Torsten Curdt wrote:
> > BTW: is it possible to set the pool size to unlimitted at all?
> >
> > I'd really make it a component because of the easy of configuration and
> > "plugin" like behaviour. A component that does not have to be released
> > would be cool for this. (following the last discussions I'd like to add:
> > I'm not quite if this really reasonable for all components because this
> > would be like implementing an additional GC in java) A "newInstance"
> > method in the ComponentManager would be sufficient for my case. So those
> > components could share the same configuation facilities but are not handle
> > inside the CM.
>
> Isn't this basically a SingleThreaded component? Where every time one is
> requested from the CM a new instance is created?
Yes... seems you are right. But do I have to release it?
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentManager and sessions
Posted by Peter Royal <pr...@managingpartners.com>.
On Thursday 21 February 2002 07:10 am, Torsten Curdt wrote:
> BTW: is it possible to set the pool size to unlimitted at all?
>
> I'd really make it a component because of the easy of configuration and
> "plugin" like behaviour. A component that does not have to be released
> would be cool for this. (following the last discussions I'd like to add:
> I'm not quite if this really reasonable for all components because this
> would be like implementing an additional GC in java) A "newInstance"
> method in the ComponentManager would be sufficient for my case. So those
> components could share the same configuation facilities but are not handle
> inside the CM.
Isn't this basically a SingleThreaded component? Where every time one is
requested from the CM a new instance is created?
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>