Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The question what the handler "returns" (better phrased: what content the handler writes) has nothing to do with the <code>IsReusable</code> property. This property makes a statement about the thread-safety of your code, not about whether the content can change. For example, a handler that writes <code>DateTime.Now</code> would be reusable. A handler that has an <code>SqlConnection</code> field and reads unchanging data would not be reusable because the connection is not thread-safe even if the data read is always the same.</p> <p>Context switching also has nothing to do with this because on a multi-core box no context switch is necessary to cause concurrency. What you mean is "thread-safety" with respect to concurrent invocations of <code>ProcessRequest</code> on the same instance of your <code>IHttpHandler</code> derived class.</p> <p>Now some practical advice: always have <code>IsReusable</code> return false and ensure that your handler class is cheap to allocate and does not bring tons of garbage with it. GC'ing a <em>single object</em> is <em>nothing</em>! My guess is the <code>IsReusable</code> property was created to give ASP.NET an artificial advantage in toy benchmarks, or to support poorly architected handlers that are expensive to create.</p> <p>If you have expensive resources (like caches) store them elsewhere (in a static field maybe).</p> <p>An easy way to obtain thread-safety is to not share anything. In that sense, don't share the handler.</p> <p><strong>TL;DR:</strong> Set <code>IsReusable</code> to false and move on. Nothing to see here. This is just a confusing design flaw in ASP.NET.</p>
 

Querying!

 
Guidance

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