^ Do objects get finalized other than in a Full GC? Could you not use these hooks?

It’s definitely a cool idea, just a difficult one to pull off well given the tools available.

Honestly, I don’t understand the concern with having a thread that frees the cached items. You don’t mind the garbage collector running, so why would you worry about a thread that watches the GC and prunes the cache? Remember, we’re talking about one thread for the entire container, not one thread per service or anything like that.

I don’t know of a way to do it with Treads. I agree with Nate about making deactivation deterministic. However, the idea of having a dedicated thread devoted to polling the lifetime container seems like a lot of overhead.

Also, if there was any way I could make deactivation deterministic without requiring interaction from client code, I would do it. There’s no event that you can subscribe to on HttpContext or Thread that will let you know when it’s disposed. As far as I can tell, there’s no way to do this effectively without polling on a background thread.

Like Levi i’m not sure i’m so keen on the background thread idea; can’t you just check the scoping reference when an object is requested or am i missing something fundamental here? It seems more likely folks will go down the deterministic route in most cases anyway, as with your HttpContext example, having objects returned scoped to some previous request until it happens to be collected doesn’t seem too useful to me.

The finalization idea could be interesting too though i wonder how frequent the disposal of these short-lived callback objects would be on a concurrent GC. Also while i think about it, if you’re using a WeakReference to monitor the scope object, i was always under the impression that weak referenced object collection was contingent on memory constraints, not necessarily “normal” pruning rules – i might be wrong though and i guess this could depend on the implementation.

Finally, maybe for deterministic expiration of (POCO) scope objects you could do something like :-

public class EventDispatchDisposer : INotifyWhenDisposed
{
public EventDispatchDisposer(Action registerEventCallback)
{
registerEventCallback(this);
}

#region INotifyWhenDisposed …
}

then:

scope = new EventDispatchDisposer(ed => pcoObj.SomeEvent += (() => ed.Dispose()));

Not sure which event you could attach to for the HttpContext example using this method.

Pools could probably be implemented by adding a maximum number of instances per scoping object. I’ve never had that much use for the pooled lifecycle though.

As far as threads go, the cache only uses one thread to watch the garbage collector for *all* activated instances — not one thread per instance. I do agree that I might be able to implement it using a finalizer though. I’ll have to think about that.

1) What about object pools? For instance, say you want to recycle object instances, instead of creating new instances every time. There’s not an obvious object to use as scope. You can’t use the pool instance, since that would result in a singleton model. I suppose you could create a pool of “scope” instances instead of objects. But managing that seems pretty difficult. Perhaps pooling would be better managed else where in the framework.

2) Why not use a finalizer? Using a thread to monitor an instance seems expensive. Instead, you could create an object which implements a finalizer which notifies the engine when called. The finalizer is called on a different thread, you’d probably want to use a different thread to prune the scope cache to allow the finalizer thread to continue to execute. You might also want to create a new “listener” object each time instead of resurrecting the same object. I’m honestly not sure which is more performance expensive, but it might be worth exploring.