IsReusable = True

Discussion in 'ASP .Net' started by Joseph Geretz, Dec 9, 2008.

  1. 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, Dec 9, 2008
    #1
    1. Advertising

  2. Joseph Geretz

    George Guest

    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
    >
    >
    >
     
    George, Dec 9, 2008
    #2
    1. Advertising

  3. "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
     
    Anthony Jones, Dec 9, 2008
    #3
  4. 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, Dec 9, 2008
    #4
  5. "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
     
    Anthony Jones, Dec 9, 2008
    #5
  6. 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
    >
     
    Joseph Geretz, Dec 9, 2008
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Angrez Singh
    Replies:
    1
    Views:
    2,947
    Brock Allen
    Apr 25, 2005
  2. IHttpHandler.IsReusable

    , Nov 21, 2005, in forum: ASP .Net
    Replies:
    2
    Views:
    4,981
    Steven Cheng[MSFT]
    Nov 23, 2005
  3. Replies:
    0
    Views:
    555
  4. Replies:
    1
    Views:
    516
    Alvin Bruney [MVP]
    Apr 27, 2007
  5. bdb112
    Replies:
    45
    Views:
    1,349
    jazbees
    Apr 29, 2009
Loading...

Share This Page