6

Using Castle Windsor, I have a component configured with the transient lifestyle:

<component id="publish.mapping.default"
                   service="IMyService, MyAssembly"
                   type="MyServiceImplementation, Myassembly" 
                   lifestyle="transient" />

Which will be used like this:

var service = container.Resolve<IMyService>(componentId);
// service usage ....
// service goes out of scope ...

My question is, will the service instance be garbage collected after it goes out of scope, or will Castle Windsor hold on to a reference ? I found this similar question, that implies that the latter might be the case - but after examining the links posted there, I am unsure whether the discussion is about holding on to the reference, or about ensuring that the object are disposed if it implements IDisposable. My objects does not need to be disposed.

If Castle Windsor holds on to the instance, is there any easy way to prevent this (perhaps by configuration) ?

EDIT
It seems, that I need to set the release tracking policy. Can this be configured in the xml config file, or does it need to be set in code ? Can the release tracking policy be set on a per-component basis ?

Community
  • 1
  • 1
driis
  • 161,458
  • 45
  • 265
  • 341

2 Answers2

9

By default, the container holds a reference to your objects (even the transient ones).

However, as @Bittercoder notes in Why does Castle Windsor hold onto transient objects?, you can change the release tracking policy. It seems that choosing

LifecycledComponentsReleasePolicy:

var policy = container.Kernel.ReleasePolicy;
container.Kernel.ReleasePolicy = LifecycledComponentsReleasePolicy;

But since the question was asked, that appears to have become the default policy.

Community
  • 1
  • 1
Blair Conrad
  • 233,004
  • 25
  • 132
  • 111
  • Thanks. Do you know whether this can be configured on a per component basis ? (See the edit to my question) – driis Feb 23 '09 at 18:44
  • I don't think so. I don't actually use Castle (I'd like to), but the docs seem to suggest that it's Kernel-wide. I'm not sure if this is the right thing to do, but it might be possible to add a custom policy that paid attention to your component type... – Blair Conrad Feb 23 '09 at 20:57
  • The setting of a release policy is container wide. In fact there is documentations that specifies that setting of a release policy is one of the first things that must be done after creating an instance of the container. If this rule is not followed then some of the components will be created using a specific release policy and other using a different. This might result in a high probability of causing memory leaks. – Chai Nov 28 '11 at 14:03
  • Page is gone. Can you show an example? (this is why links are bad in answers.) – Sinaesthetic Oct 24 '16 at 18:16
1

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.

Craig Vermeer
  • 1,987
  • 19
  • 29
  • Haven't checked the source, but Reflector seems to suggest that this is indeed the case in the DefaultKernel constructor. Handy to know, thanks! – Gavin Sep 24 '10 at 09:12
  • So what does this really mean? That the leak shouldn't be a problem with transient? – Sinaesthetic Oct 24 '16 at 18:38