Dependencyinjection: Dispose services in order

Created on 8 Nov 2016  路  4Comments  路  Source: aspnet/DependencyInjection

Services should be disposed in the reverse order that they were created.

If service A depends on service B, B will be created first, then A. Now when Dispose() is called on A, it could have to use B. Unfortunately B might already be disposed as the order is not deterministic and based on a dictionary entry. I suggest we enforce the disposal order to be both logical and deterministic as far as the dependency order is defined.

3 - Done bug

Most helpful comment

Thanks for the loop-in! This sounds like another case where making assumptions in the framework could cause issues for some container integrations.

Reverse-order disposal is necessary to correctly tear down some component graphs, e.g. where A : IDisposable "registers" itself with B : IDisposable on creation, and "un-registers" on disposal, but:

  • The framework could avoid these kinds of object graphs, or
  • Some additional code could be added, e.g. mediator objects, to make the scenarios work independently of disposal order.

If users want forward-order disposal they should be free to depend on it by selecting a container that implements it - and vice-versa. Personally, I feel reverse-order is the _right_ way to do it, but it's highly unlikely everyone agrees with me ;-)

433 is a discussion along these lines - disposal order would be a good item to add to the summary on that ticket, I think.

All 4 comments

I have a branch that implements this in our container and adds specification tests but I have couple of concerns:

  1. We are not requiring IServiceProvider to be IDisposable in specification but adding this tests forces it. Neither Autofac not StructureMap implementation of IServiceProvider is IDisposable
  2. Autofac does this in correct order but StructureMap disposes services in the order of creation.

@khellang @nblumhardt what are your thought on this?

Thanks for the loop-in! This sounds like another case where making assumptions in the framework could cause issues for some container integrations.

Reverse-order disposal is necessary to correctly tear down some component graphs, e.g. where A : IDisposable "registers" itself with B : IDisposable on creation, and "un-registers" on disposal, but:

  • The framework could avoid these kinds of object graphs, or
  • Some additional code could be added, e.g. mediator objects, to make the scenarios work independently of disposal order.

If users want forward-order disposal they should be free to depend on it by selecting a container that implements it - and vice-versa. Personally, I feel reverse-order is the _right_ way to do it, but it's highly unlikely everyone agrees with me ;-)

433 is a discussion along these lines - disposal order would be a good item to add to the summary on that ticket, I think.

Was this page helpful?
0 / 5 - 0 ratings