How to know whether a serviced component comes from a pool or not

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

For debugging purposes, it may be useful to know whether an object that has
been constructed from a client (via a new XX) is going to come from a pool
(assuming pooling is enabled for that serviced component) or not.

All I have been able to find is ServicedComponent.Activate which is virtual.
However this does not give me any info regarding whether it is a new object
or comes from a pool!

Am I missing something here?
 
Juan Dent said:
Hi,

For debugging purposes, it may be useful to know whether an object that
has
been constructed from a client (via a new XX) is going to come from a pool
(assuming pooling is enabled for that serviced component) or not.

All I have been able to find is ServicedComponent.Activate which is
virtual.
However this does not give me any info regarding whether it is a new
object
or comes from a pool!

Am I missing something here?

You have to override Activate(), whenever it's called you know that it's
instance is taken from the pool.

protected override void Activate() {
// He! I'm a pooled instance.
// do some specific processing when activated from the pool.
}

Same goes for CanBePooled and Deactivate, you should override these if you
need to perform some special processing when called.
So, CanBePooled should return true if you want this instance to return to
the pool.
Deactivate is called when the instance returns to the pool.
Another overridable is Construct, this gets called whenever a 'fresh'
instance is created.

Willy.
 
Hi

I reviewed the thread and find that there is a related issue in the
newsgroup below. And I will reply to you in that queue, you may monitor it.
Subject: Watching the COM+ pool
Newsgroups: microsoft.public.dotnet.framework

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
A slight correction if I may:

--protected override void Activate() {
-- // He! I'm a pooled instance.
-- // do some specific processing when activated from the pool.
--}

If the class is not pooled but has JITA enabled, then Activate gets called
upon activation, not because it is being taken out of the pool.

Also, I don't see this behavior either if the component is pooled or JITA or
both:

--Another overridable is Construct, this gets called whenever a 'fresh'
--instance is created.

My assumption is that Construct will be called ONLY when Construction is
enabled via attributes or the CSE.

Is this correct?


--
Thanks in advance,

Juan Dent, M.Sc.
 
Inline

Willy.

Juan Dent said:
A slight correction if I may:

--protected override void Activate() {
-- // He! I'm a pooled instance.
-- // do some specific processing when activated from the pool.
--}

If the class is not pooled but has JITA enabled, then Activate gets called
upon activation, not because it is being taken out of the pool.
No, Activate is called whenever the object is taken from the pool.
'Deactivate' when an "activated" object gets released.
Also, I don't see this behavior either if the component is pooled or JITA
or
both:
You must have 'Component supports events and statistics' enabled.
--Another overridable is Construct, this gets called whenever a 'fresh'
--instance is created.

My assumption is that Construct will be called ONLY when Construction is
enabled via attributes or the CSE.

Is this correct?
Yep, "Construct" is called when the Object Construction is enabled, but only
when a fresh instance is created, NOT when the object is taken from the
pool.
The same goes for the objects contructor, it's only called when a new
instance is created, NOT whe taken from the pool.
..
..
 
An example I have shows that Activate() is called not only when pooling is
enabled and the object is taken from the pool, but EVEN in the abscence of
pooling, if JITA is enabled, then Activate()/Deactivate() are called each
time the object is activated/deactivated...

Thus we have a contradiction or we differ in some other setting. ??
--
Thanks in advance,

Juan Dent, M.Sc.
 
Well, I didn't say it's not called in a JITA scenario, I said it's called
when an instance is taken from the pool even when JITA is not enabled.
Both JITA and Pooling are different concepts, but they can, and are mostly
used in tandem.
Note that both JITA and pooling have different semantics, a pooled non-JITA
object is activated when the client creates an instance, a JITA (pooled or
not) object is activated (when not allready activated) when the client calls
a method. A pooled JITA object behaves like a JITA.
The same goes for the deactivation, a pooled non-JITA object is deactivated
when the client releases it's reference, a JITA object (pooled or not)
deactivates when the method returns with the Done bit is set to
true(automatically or manually). A pooled JITA, deactivates also when the
client releases it's reference.

Willy.


In JITA scenario's Activate is being called when activated in a context
 
Back
Top