Why does Castle Windsor hold onto transient objects?

Question

Recently I noticed my application appears to be eating memory that never gets released. After profiling with CLRProfiler I've found that the Castle Windsor container I'm using is holding onto objects. These objects are declared with the lifestyle="transient" attribute in the config xml.

I've found if I put an explicit call to IWindsorContainer.Release(hangingObject), that it will drop its references.

This is causing a problem though, I wasn't expecting that with a transient lifestyle object CastleWindsor would keep a reference and effectively create a leak. It's going to be a rather mundane and error prone task going around inserting explicit Release calls in all the appropriate places.

Have you seen this problem, and do you have any suggestions for how to get around it?

Answer 1

I think this might be it. Apparently, if you do keep hold of the container, it will keep transient objects alive, and to solve the leak, explicit calls to Release are required!

http://www.nablasoft.com/Alkampfer/?p=105

I wonder how many people have leaky applications because 'transient' doesn't do what it says on the tin.

Answer 2

You can set a lifestyle of singleton or transient though on objects in the container. Singleton objects I understand should last the life of the application, but I don't understand the usefulness of this behvaviour being the same for transient ones!

Custom lifestyles can be created by implementing ILifestyleManager. Maybe it's possible to implement this suitably to create a ReallyTransient lifestyle type!

Answer 3

I think the answers here are missing a vital point - that this behavior is configurable out of the box via release policies - check out the documentation on the castle project site here.

In many scenarios especially where your container exists for the lifetime of the hosting application, and where transient components really don't need to be tracked (because your handling disposal in your calling code or component that's been injected with the service) then you can just set the release policy to the NoTrackingReleasePolicy implementation and be done with it.

Prior to Castle v 1.0 I believe Component Burden will be implemented/introduced - which will help alleviate some of these issues as well around disposal of injected dependencies etc.

Edit:

Check out the following posts for more discussion of component burden.

The Component Burden - Davy Brions

Also component burden is implemented in the official 2.0 release of the Windsor Container.

Answer 4

One thing to note is that this seems to have been fixed in the Castle Trunk. In r5475, Hammett changed the default release policy in MicroKernel to LifecycledComponentsReleasePolicy.