Use Slim reader/writer locks over tenant-scope Dictionary? about autofac.multitenant HOT 3 CLOSED

Are you running into an issue where changing the current mechanism is required? I'm open to change if there's a reason, but it needs to be something quantifiable like a consistent perf improvement (ie not just an improvement during tenant registration, which is a relatively uncommon path).

from autofac.multitenant.

That's a good point. I was thinking in terms of refactoring as part of expanding the current interaction points with the tenant dictionary, partly in response to #5 . Really I just wanted to make sure that it wasn't precluded somehow.

I thought I recalled some debate about this, or maybe about locking in general. I saw the issue reference in https://github.com/autofac/Autofac.Multitenant/blob/develop/src/Autofac.Multitenant/MultitenantContainer.cs, but couldn't track it down (dates back to Google Code, I'm guessing?).

Sounds like the only issue is avoiding premature/unnecessary optimization. If so, please close this issue. Thanks!

from autofac.multitenant.

I think it might be premature optimization. Since configuring (or reconfiguring) tenants shouldn't be something that happens, say, on a per-request basis in a web app or something, it all should be in an uncommon path where a difference of a few ms doesn't make or break the app. However, when we get to addressing the reconfiguration of tenants, we'll keep in mind potentially updating locks to be different if needed. I'll make a note in that issue so we don't forget. Thanks!

from autofac.multitenant.