Caliburn.Micro.Autofac icon indicating copy to clipboard operation
Caliburn.Micro.Autofac copied to clipboard

Is this library not causing a massive memory leak?

Open cosminonea opened this issue 12 years ago • 1 comments

Here is a quote from http://nblumhardt.com/2011/01/an-autofac-lifetime-primer/

// var container = … while (true) { using (var lifetimeScope = container.BeginLifetimeScope()) { var r = lifetimeScope.Resolve<IMyResource>(); // r, all of its dependencies and any other components // created indirectly will be released here } }

"This is all it takes to avoid memory and resources leaks with Autofac. Don’t resolve from the root container. Always resolve from and then release a lifetime scope."

I see that Caliburn.Micro.Autofac resolves only from the root container and never releases the components. Have you ever load tested this with components that are PerDependency()? Or is the requirement to have only Singletons in the container?

Suppose you have a WPF application that talks to the database using a Db/ObjectContext. If you register the context as singleton you'll end up with all the database in memory after a while. If you register it PerDependency you'll end up with thousands of them in memory.

This is actually the common problem with the ServiceLocator pattern.

I guess CM should support something like IUnitOfWork and when a view model implements it, CM should start a lifetime scope and everything should be resolved from it.

cosminonea avatar Nov 19 '12 22:11 cosminonea

I have looked into creating a child scope for the Caliburn.Micro types, but always run into the same issue of stronly imposing on the end user. I have been toying around recently with with exposing 2 containers - Root and a Caliburn scoped one, perhaps it is time to revisit.

dbuksbaum avatar Nov 25 '12 15:11 dbuksbaum