When does IsReusable Property get interrogated?

[Joseph Geretz]

Can I rely on this property being interrogated after ProcessRequest has
finished executing?

I'm looking for an 'event' that I can use to know when the object is about
to be placed into the Pool. If the .NET runtime consistently interrogates
IsReusable after every call to ProcessRequest, then I'd be able to leverage
this.

Is there a specification which documents exactly when IsReusable is
accessed?

Thanks!

- Joseph Geretz -

 

[Patrice]

What are you trying to do ? Perhaps
http://msdn.microsoft.com/en-us/library/system.web.httpapplication.postrequesthandlerexecute.aspx
could fit your needs ? What are you trying to do ?

Else you would need to in your own code and check
referencesource.microsoft.com ? Plus it will be obscur and could perhaps
break in the future.

 

[Joseph Geretz]

Hi Patrice,

What I'm trying to do is ensure that the database connection is closed when
a transaction handler is released to the pool. All of my transaction
handlers derive from the same base class - eRxProcessor, which implements
the IhttpHandler interface. The eRxProcessor instantiates our DataBroker
class, which opens a DB connection, and provides the Databroker to its
derived classes via a protected property. If I can implement the close of
the DB connection in the eRxProcessor base class, I can guarantee that
pooled objects aren't going to be holding onto open connections, without
having to rely on the developers, who develop the derived classes to do so.
The pattern you suggest would be applicable to an HttpModule since it
receives these events. However, our transaction handlers are implemented as
HttpHandlers; these do not receive these events.

I understand that IsReusable is used to describe whether a particular class
instance is reusable or not. However, this describes only a small subset of
the spec for the IsReusable property. I haven't found the documentation to
describe exactly when IsReusable is called. Is it called when the instance
is created intially? Or is it called when its client releases its reference?
There is a world of difference between these two patterns, the most obvious
being whether an instance can begin 'life' as a poolable object, and then
subsequently switch itself into a non-poolable state due to conditions
encountered on a subsequent access. Another benefit to the latter patern
would be the ability to receive notification when the object is about to be
released into the pool (or not).

Is this stuff documented? Or do I have to prototype this to fill the gap in
the documentation?

Thanks,

Joseph Geretz

 

[Joseph Geretz]

Follow up:

The pattern you suggest would be applicable to an HttpModule since it
receives these events. However, our transaction handlers are implemented
as HttpHandlers; these do not receive these events.

Actually, there is a way in which this event can be leveraged. Since the
HttpModule can get a reference to the HttpHandler which handled the request,
the following code does exactly what I'm looking to accomplish at the exact
point in the transaction processing which you suggest:

((eRxProcessor)HttpContext.Current.Handler).CloseDatabase();

Thanks very much for your help!

Joseph Geretz