2
votes

We're using Castle Windsor 2.1.0.6655.

I'm wanting to use transient lifecycle for my resolved objects, but I'm wanting to check how this version of Castle deals with transients that have dependencies. If I use my immediate window (visual studio), I can see the effects of resolving, disposing, and finally realeasing, all the time checking whether the resolved object is released.

eg.

resolved = container.Resolve(Id);

container.Kernal.ReleasePolicy.HasTrack(resolved)
= true

resolved.Dispose()
container.Kernal.ReleasePolicy.HasTrack(resolved)
= true

container.release(resolved)
container.Kernal.ReleasePolicy.HasTrack(resolved)
= false

My concern is that these objects are continuing to be tracked between requests, as they are never released, meaning memory usage continues to rise.

I've read that Component Burden is related to this issue, but I haven't been able to find out exactly what this is in Castle 2.0 and greater.

The difficulty in 'releasing' is that the resolved objects are in fact part of services, their usage being to provide ORM functions and mappings. I'm not sure that referencing the container to release is correct in these instances.

I'm wondering whether there is a way for me to see how many objects the container is referencing at a given point, without having to use memory profilers, as we don't have this available.

I thought I could maybe use the following:

container.Kernel.GetHandlers()

with the type I'm looking for, to see if tracked occurrences are increasing?

2

2 Answers

4
votes

Vesion 2.1 will celebrate its 4th birthday very soon. I strongly recommend you to upgrade to version 3.1.

Not only because v2.1 is no longer supported and v3.1 is much newer, with many bugfixes, but also it has some major improvements in the way it does tracking.

Also in v3.1 you will be able to enable a performance counter, that will report to you, in real time, the number of instances being tracked by the release policy.

Addressing the particular concern you're referring to, that sounds like an old threading bug that was fixed somewhere along the way. One more reason to upgrade.

0
votes

windsor has to be used with R(egister)R(esolve)R(elease) pattern.

by default(you definitely should stick with that...) all components are tracked/owned by the container... that's the windsor beauty!

Until you (or the container itself) calls Release the instance will be hold in memory, no matter if you call the Dispose directly(as per you sample).

Said so, components registered as Transient should be called w/ composition root only in other word as first object of the dependency graph or through a factory(late dependency). Of course keep in mind that using a factory within dependency graph you may need to implement RRR pattern expliclty.