Databases
StackOverflow2013
Postsdbo
POAutofac resolving a singleton creates a bottleneck
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POAutofac resolving a singleton creates a bottleneck
    primarykey
    data
    text
    <p>I'm using Autofac in an asp.net MVC app and came across a problem with locking. Anytime a service depends on a singleton, that service is resolved from the root lifetime scope. This is because Autofac:</p> <ul> <li>resolves singleton components from the root scope</li> <li>resolves any components from the root scope who have dependencies that must be resolved from root.</li> </ul> <p>Further, when resolving from any scope, Autofac locks that scope. I think these are fine design decisions. My problem is with misbehaving classes who depend on singletons <strong>and</strong> have slow constructors. These create a bottleneck for anyone else needing to resolve a singleton. </p> <p>Since this is in a MVC app, each request is getting mapped to some MVC controller that's constructor injected. Further, most of my controllers take dependencies on various singleton services (logging, caching, etc). </p> <p>For things with fast constructors this is not a problem. But as soon as one poorly written class is requested, my throughput tanks because every new request is blocked on that misbehaving constructor. For example:</p> <p><strong>given these 3 classes</strong></p> <pre><code>//registered as SingleInstance() class MySingleton {} class BadTransient { public BadTransient(MySingleton s) { Thread.Sleep(5000); } } class FriendlyTransient {} </code></pre> <p><strong>resolved like</strong></p> <pre><code>using(var scope = container.BeginLifetimeScope("nested scope")) { //resolves from child scope var myFriend = scope.Resolve&lt;FriendlyTransient&gt;(); //resolves from root because it's a singleton var singleton = scope.Resolve&lt;MySingleton&gt;(); //resolves from root because it has a singleton dependency. //**** this locks the root scope for 5 seconds //**** no one else can resolve singletons. var troublemaker = scope.Resolve&lt;BadTransient&gt;(); } </code></pre> <p><strong>Is there a way I can avoid this bottleneck?</strong></p> <p>The obvious answer is to have fast constructors. The reality is that not all the constructors in my codebase can be guaranteed to be fast. There's <em>a lot</em> of legacy code, there's lots of code that relies on 3rd party code, there's code that looks fast but depends on code that isn't, there's code that's usually fast but breaks down in odd circumstances, etc. Educating developers only works to a certain extent. </p> <p>We've been fixing constructors as we find them, but I need a more proactive solution. It's not acceptable to let my users do my QA.</p> <p><em>Note: I don't care as much about slow constructors that don't depend on a singleton. They will lock their lifetime scope, but it won't block other threads</em></p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USdan
    1. USdan
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POAutofac resolving a singleton creates a bottleneck
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POAutofac resolving a singleton creates a bottleneck
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POAutofac resolving a singleton creates a bottleneck
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI don't see any problems with how Autofac works. Where I see the problem in that you have some `BadTransient` class where you have expensive logic in the constructors. I would move out all the logic from the constructors to an `Initialize` method which can be called by the Autofac `OnActivated` event. So there is no need to lock the scope for the whole initialization time.
      singulars
      1. POAutofac resolving a singleton creates a bottleneck
      1. USnemesv
    2. CO@nemesv please see my edits
      singulars
      1. POAutofac resolving a singleton creates a bottleneck
      1. USdan
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload