«

Is there any sort of lifecycle event which my object (implements
IHttpHandler) receives when it is released to the pool, or retrieved from
the pool?

Naturally, I need to keep these objects as stateless as possible, however
some intra-transaction state accumulation is necessary. It would be helpful
to have an event which is fired when the instance is retrieved from the pool
so that pre-transaction initialization can be performed to ensure that the
object is in its pristine state ready to being the next transaction. In my
case,
these objects derive from a base class and so I could implement such
pre-initialization in the base class.

Thanks for your advice,

Joseph Geretz

A bit confused. Why do you need it?
You have your ProcessRequest. Just initialize your Handler in first line of
that method.
That would be the 'event' that your Handler realease from the pool.

George.

"Joseph Geretz" <> wrote in message
news:...
> Is there any sort of lifecycle event which my object (implements
> IHttpHandler) receives when it is released to the pool, or retrieved from
> the pool?
>
> Naturally, I need to keep these objects as stateless as possible, however
> some intra-transaction state accumulation is necessary. It would be
> helpful
> to have an event which is fired when the instance is retrieved from the
> pool
> so that pre-transaction initialization can be performed to ensure that the
> object is in its pristine state ready to being the next transaction. In my
> case,
> these objects derive from a base class and so I could implement such
> pre-initialization in the base class.
>
> Thanks for your advice,
>
> Joseph Geretz
>
>
>

"Joseph Geretz" <> wrote in message
news:...
> Is there any sort of lifecycle event which my object (implements
> IHttpHandler) receives when it is released to the pool, or retrieved from
> the pool?
>
> Naturally, I need to keep these objects as stateless as possible, however
> some intra-transaction state accumulation is necessary. It would be
> helpful
> to have an event which is fired when the instance is retrieved from the
> pool
> so that pre-transaction initialization can be performed to ensure that the
> object is in its pristine state ready to being the next transaction. In my
> case,
> these objects derive from a base class and so I could implement such
> pre-initialization in the base class.
>

I'm not sure I understand this. Are you saying that you maintain some state
in the handler between requests? This state is may be related to an in
progress transaction? How would you guarantee that subsequent requests
would pick up the correct instance of the handler involved in the
transaction?

You can determine that the handler is retrieved from the pool then its
ProcessRequest method is called. At that point its either a fresh instance
or an instance retrieved from the pool, you could use a prvate boolean feild
to track that.

There is no specific event that tracks pool removal, you would need to use a
finalizer (implement the IDisposable interface). That wouldn't tell you
when the item was dropped from the pool immediately only when its finally
GCed, however since both operations are arbitary it wouldn't make much
difference.

--
Anthony Jones - MVP ASP/ASP.NET

Thanks guys,

Both responses indicated that ProcessRequest is immediately called upon
retrieval from the pool. This is in fact where we have implemented
transaction initialization code which runs when a transaction start.

All of our transaction processors derive from a base transaction processor
class. The base implements IHttpHandler, and so all of the derived classes
do as well. The base implements the IsReusable method and sets the return
value to true so all derived classes are now pooled. Developers of the
derived classes don't need to do anything to make this happen since this
behavior is all inherited from the base class.

Derived classes naturally implement ProcessRequest; obviously - this is how
each transaction implements its own particular processing. So transaction
developers can implement whatever pre-transaction processing is necessary at
the commencement of this method. What I was looking for is a way to
implement application-wide transaction pre-processing in the base class in a
manner which precludes reliance on the transaction developers to properly
implement such.

Is there any way to do this? Or do I need to simply rely on the developers
of the derived transaction classes to take care of this?

Thanks for your advice!

Joseph Geretz

"Anthony Jones" <> wrote in message
news:%...
> "Joseph Geretz" <> wrote in message
> news:...
>> Is there any sort of lifecycle event which my object (implements
>> IHttpHandler) receives when it is released to the pool, or retrieved from
>> the pool?
>>
>> Naturally, I need to keep these objects as stateless as possible, however
>> some intra-transaction state accumulation is necessary. It would be
>> helpful
>> to have an event which is fired when the instance is retrieved from the
>> pool
>> so that pre-transaction initialization can be performed to ensure that
>> the
>> object is in its pristine state ready to being the next transaction. In
>> my case,
>> these objects derive from a base class and so I could implement such
>> pre-initialization in the base class.
>>
>
> I'm not sure I understand this. Are you saying that you maintain some
> state in the handler between requests? This state is may be related to an
> in progress transaction? How would you guarantee that subsequent requests
> would pick up the correct instance of the handler involved in the
> transaction?
>
> You can determine that the handler is retrieved from the pool then its
> ProcessRequest method is called. At that point its either a fresh
> instance or an instance retrieved from the pool, you could use a prvate
> boolean feild to track that.
>
> There is no specific event that tracks pool removal, you would need to use
> a finalizer (implement the IDisposable interface). That wouldn't tell you
> when the item was dropped from the pool immediately only when its finally
> GCed, however since both operations are arbitary it wouldn't make much
> difference.
>
> --
> Anthony Jones - MVP ASP/ASP.NET
>

"Joseph Geretz" <> wrote in message
news:...
> Thanks guys,
>
> Both responses indicated that ProcessRequest is immediately called upon
> retrieval from the pool. This is in fact where we have implemented
> transaction initialization code which runs when a transaction start.
>
> All of our transaction processors derive from a base transaction processor
> class. The base implements IHttpHandler, and so all of the derived classes
> do as well. The base implements the IsReusable method and sets the return
> value to true so all derived classes are now pooled. Developers of the
> derived classes don't need to do anything to make this happen since this
> behavior is all inherited from the base class.
>
> Derived classes naturally implement ProcessRequest; obviously - this is
> how each transaction implements its own particular processing. So
> transaction developers can implement whatever pre-transaction processing
> is necessary at the commencement of this method. What I was looking for is
> a way to implement application-wide transaction pre-processing in the base
> class in a manner which precludes reliance on the transaction developers
> to properly implement such.
>
> Is there any way to do this? Or do I need to simply rely on the developers
> of the derived transaction classes to take care of this?
>

Sounds to me you need to create a life-cycle for your derived classes.
First thing is to take away the responsibility to handle ProcessRequest from
your derived classes.

Have your base class implement IHttpHandler explicitly. Hence execution
starts in the base class (unless the derived class implements a default
constructor).

Now have your base class expose some protected virtual (or abstract) methods
that your IHttpHandler.ProcessRequest method will call in sequence along
with calling private methods of the base class that do other things you need
done.

You now have control over the order in which things happen and in particular
your base class gets to define what happens first and what happens last.

--
Anthony Jones - MVP ASP/ASP.NET

Thanks Anthony,

This sounds like a great solution. Is there a name for this design pattern,
where the base class calls into the derived class, rather than vice versa?

Can you recommend a good book on OOP design patterns? (C# would be a plus
because that's currently the language I'm working with, but a
language-agnostic reference would be useful as well.)

Thanks!

Joseph Geretz

"Anthony Jones" <> wrote in message
news:...
> "Joseph Geretz" <> wrote in message
> news:...
>> Thanks guys,
>>
>> Both responses indicated that ProcessRequest is immediately called upon
>> retrieval from the pool. This is in fact where we have implemented
>> transaction initialization code which runs when a transaction start.
>>
>> All of our transaction processors derive from a base transaction
>> processor class. The base implements IHttpHandler, and so all of the
>> derived classes do as well. The base implements the IsReusable method and
>> sets the return value to true so all derived classes are now pooled.
>> Developers of the derived classes don't need to do anything to make this
>> happen since this behavior is all inherited from the base class.
>>
>> Derived classes naturally implement ProcessRequest; obviously - this is
>> how each transaction implements its own particular processing. So
>> transaction developers can implement whatever pre-transaction processing
>> is necessary at the commencement of this method. What I was looking for
>> is a way to implement application-wide transaction pre-processing in the
>> base class in a manner which precludes reliance on the transaction
>> developers to properly implement such.
>>
>> Is there any way to do this? Or do I need to simply rely on the
>> developers of the derived transaction classes to take care of this?
>>
>
> Sounds to me you need to create a life-cycle for your derived classes.
> First thing is to take away the responsibility to handle ProcessRequest
> from your derived classes.
>
> Have your base class implement IHttpHandler explicitly. Hence execution
> starts in the base class (unless the derived class implements a default
> constructor).
>
> Now have your base class expose some protected virtual (or abstract)
> methods that your IHttpHandler.ProcessRequest method will call in sequence
> along with calling private methods of the base class that do other things
> you need done.
>
> You now have control over the order in which things happen and in
> particular your base class gets to define what happens first and what
> happens last.
>
> --
> Anthony Jones - MVP ASP/ASP.NET
>