1

I have several Repository classes that are mapped as InRequestScope so that they are cached for the lifetime of the request.

These Repository classes are injected with a CacheClass that is mapped as InSingletonScope.

It seems that because the Repository class references an object that is in the InSingletonScope, the Repository class is also considered as being in the InSingletonScope, despite it being mapped as InRequestScope.

How can I force Ninject to dispose of the Repository classes at the end of the Request whilst also keeping the CacheClass in cache for injection into the next Repository class created during the next request?

Seems like this should be simple to do but I can't get my head around it.

Ibraheem
  • 2,168
  • 20
  • 27
  • 1
    Can you provide some code to prove the assumption that `because the Repository class references an object that is in the InSingletonScope, the Repository class is also considered as being in the InSingletonScope`? – qujck Oct 22 '13 at 08:05
  • This is what Ninject is supposed to do. So either you are doing something wrong or you found a bug. But without any code sniüüets it is impossible to tell which one is the case in your situation. – Remo Gloor Oct 22 '13 at 13:56
  • I've done a little more digging today, seems the issue is not as described above, but the Repository classes seem to be re-used across requests. I assumed the above since setting the CacheClass to the SingletonScope removed the weirdness. I'll do some more work and get back to this question. Thanks. – Ibraheem Oct 22 '13 at 14:53
  • Alright it seems the fault was not with the Repository classes at all, but with concurrency of the requests leading to a race condition for the database, which appeared to be re-use of the Repository. Should I delete this question? – Ibraheem Oct 22 '13 at 17:12
  • At least I've confirmed Ninject is working as it should be in my application lol – Ibraheem Oct 22 '13 at 17:13

0 Answers0