Development With A Dot

Blog on development in general, and specifically on .NET

Sponsors

My Friends

My Links

Permanent Posts

Portuguese Communities

Enterprise Library Lifetime Managers

Update: fixed a bug in the attached code.

Enterprise Library comes with several lifetime manager, which you can use to control how your objects are stored and retrieved. The available lifetime managers are:

  • ExternallyControlledLifetimeManager: stores a weak reference to objects which are created elsewhere
  • PerThreadLifetimeManager: stores objects in a thread static dictionary)
  • ContainerControlledLifetimeManager (the default): stores objects in the Unity container
  • TransientLifetimeManager: does not store objects, create a new one every time it is requested

In web applications, we may need additional options, for example:

  • Store objects in the current session
  • Store objects in the current request
  • Store objects in the current application

So, I wrote three new lifetime managers, for each of these requirements: WebSessionLifetimeManager, WebRequestLifetimeManager and WebApplicationLifetimeManager. Another possibility would be a pooled lifetime manager, which will be the subject for a future post.

Posted: Mar 08 2009, 10:39 AM by Ricardo Peres | with 4 comment(s)
Filed under: , , ,

Comments

Brett Jacobson said:

Ricardo, I'm trying to use this code, and its not doing something right for me.  What I'm finding is that these Lifetime Managers don't appear to be hooked up to the lifetime as advertised.  There doesn't seem to be any "hook" such that WebRequestLifetimeManager calls RemoveValue() on its items at the end of the lifecycle of the Request (also applies to Session).  It looks like they're all tied to the lifetime of the Application object;  I'm using the Request one, and it looks like my objects are getting new'ed up on a request just fine, but they aren't getting RemoveValue'() at the end of the request which is what I expected.   When the appdomain dies (i set its idle timeout to 1 minute to ease debugging), RemoveValue() is getting called for all the objects that were ever SetValue()'ed.  But since HttpContext.Current.Items doesn't exist anymore, its blown up.  one workaround might be to check for session and Request to not be null, but it looks like the items are not getting Disposed of explicitly, only implicitly (which may be bad).  This is causing NullReferenceException's in w3wp.exe when the domain dies.  Any ideas?

# March 10, 2009 1:00 PM

Ricardo Peres said:

Hi, Brett!

Yes, you are right: there was a bug in my code. I have uploaded a new version.

Regarding your problem, the only way to do this is by using a module that hooks to the EndRequest event, and have the request lifetime manager register objects on this module. I have included the source code, have a look.

What happens is that objects were only removed when the lifetime manager was garbage collected.

Regarding session and application, there other problems: you cannot hook the SessionEnd and ApplicationEnd events from a module, so the code would have to go to Global.asax.cs. It is better if your objects do not need or rely of any disposing mechanism.

Regards,

Ricardo

# March 10, 2009 1:43 PM

Dave Hayden said:

The problem is that often the objects do need to implement IDisposable and do need to be disposed of during their lifetime.

Better to not try to do this with a custom lifetime manager but with child containers with disposable objects that can be disposed of on each request for proper cleanup.

Regards,

Dave

# March 11, 2009 11:48 AM

Ricardo Peres said:

Hi, Dave, thanks for your comment! It's an honor to have a guy like you post a comment on a blog of a guy like me! :-)

I will look more into it... My solution allows for proper termination of objects through the IDisposable interface at the end of requests, but, sadly, not at the end of sessions. I will try to reproduce it with child containers.

Best regards,

Ricardo

# March 12, 2009 4:24 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)