3

We're using Unity to provide dependency injection within the WCF service layer for our current project, and we have followed examples such as the following to write a service host factory, service host, service behaviour and instance provider:

http://avingtonsolutions.com/blog/post/2008/08/02/Uisng-Unity-with-a-WCF-Service.aspx

The solution works very successfully, but we have need to provide contextual resolution of objects on a per-request basis. So far, we have implemented this by creating a child container within the GetInstance method of the instance provider, adding the contextual registrations to the child container, and using the child container to perform the resolution of the service type. Some registrations in both containers use container controlled lifetimes.

As I do not know the lifetime of the child container, I have concerns about this methodology: 1) Does the child container go out of scope at the end of the GetInstance method and therefore get disposed leading to some of our our container resolved objects being disposed in the middle of our request?

2) Alternatively, does the parent container cling on to the child container for some period of time meaning that it will rapidly fill with child container instances in a high traffic environment?

Can anyone point me in the right direction?

Justin
  • 564
  • 4
  • 13
  • Do you want to be able to keep context-variables per-request? Such as setting a value from a request header, that is valid through the request (and only within the request) and then disposed? – smoksnes Apr 14 '16 at 05:40
  • This question was from some time ago, but I think what I wanted to do was register into the container context specific instances that were dependent on things like headers. That was all working just fine, but my query was really about the lifetime of Unity child containers in this context. – Justin Apr 29 '16 at 13:47

0 Answers0