views:

274

answers:

4

Autofac newbie here, but I like what I see so far. I'm trying to take advantage of request-lifetime of my resolved objects and I'm having trouble confirming that a dispose is actually happening after a request is done.

I have a disposable object that I get at the start of a page request and dispose at the end. I'm using autofac to get an instance of the object now and I wanted to see if autofac would do the disposing for me.

i've instrumented the Dispose() method on the object in question, and i can see it 'fire' when my page does the lifetime management. I see no evidence when I don't dispose myself but let autofac do it.

I'm using these instructions to get thigns configured, including the web.config and global.asax changes. I am able to instantiate the object just fine but I can't tell if it's really being disposed. Is there another step?

A: 

Dispose is nothing more than an interface that allows you to define a "Dispose" method. The most common use for requiring a disposable class is if there are resources in that class that should be freed explicitly (such as a windows resource handle). For the most part the IDisposable interface is not required, as the garbage collector is extremely powerful and will do a much better job at managing memory. However, obviously there are plenty of cases where handles must be freed immediately, which brings me on to the next point, implementation of IDisposable.

What NOT to do:

var myClass = MyDisposableClass();

// do stuff with myClass

myClass.Dispose();

Proper usage:

using (var myClass = MyDisposableClass()) { // do stuff with myClass }

The compiler will effectively build the same as the following:

MyDisposableClass myClass = MyDisposableClass(); try { // do stuff with myClass } finally { myClass.Dispose(); }

The important distinction being that no matter what happens, you know your Dispose will get called. In addition, you can tie a destructor (which if exists, is called by the Garbage Collector) which you can then tie in to call your Dispose method; but if you need to do this for whatever reason be sure to not free the same resource twice (set your pointers to null after releasing).

Hope this helps.

Aaron
Thanks for taking the time. I know how dispose works. My goal was to be able to swap in and out implementations without the page having to know whether they were disposable or not. Autofac's sub-container lifecycle management is supposed to do that, and the ASP.NET integration is supposed to manage that for the lifetime of a request. I just wanted to confirm that it was actually happening.
n8wrl
+1  A: 

Whether you dispose the object manually within the page or let the Autofac module do it, there will be a difference in when your object is disposed in respect to the request lifecycle. The Autofac ContainerDisposalModule will not dispose the Request container, and with it your object, until the HttpApplication.EndRequest is fired, which is at the very end of the request lifecycle.

Depending on how you are tracing the call to your objects Dispose method, there could be a possibility that you don't see the output. How are you instrumenting your Dispose method?

Peter Lillevold
Great question, peter - I've tried three things. The first two showed nothing - response.write and httpcontext.trace, both of which could be explained by the timing. But the third is event log writing which also shows nothing.
n8wrl
I agree. Tracing to event log shouldn't be affected by request lifecycle. Hm.
Peter Lillevold
A: 

Repeat of answer from your re-post:

Most of the time this happens (in any IoC container) you'll find that one component along a chain of dependencies is a singleton.

E.g.

A -> B -> C

If A is 'factory', B is 'singleton' and C is 'factory', then resolving A will get a reference to the singleton B, which will always reference the same C.

In order for a new C to get created every time you resolve A, B must also be 'factory'.

Nicholas Blumhardt
A: 

I figured it out!

I was asking the WRONG container for the object instance - I was asking the application-container for the object and not the request-container.

D'oh!

n8wrl
Yeah this problem is usually great to figure out. I usually use more of the DI facilities instead of the service locator facilities so I don't run into this. The one time I had a nhibernate ISession being referred locked my development database... Lots of fun there.
Min