Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Yes <a href="https://stackoverflow.com/questions/3653009/entity-framework-and-connection-pooling/3653392#3653392">do not share context</a> and use one context per request. You can also check linked questions in that post to see all problems which a shared context caused.</p> <p>Now about Unity. Idea of <code>PerCallContextLifetimeManager</code> works but I think provided implementation will not work for more than one object. You should use <code>PerHttpRequestLifetimeManager</code> directly:</p> <pre><code>public class PerHttpRequestLifetime : LifetimeManager { // This is very important part and the reason why I believe mentioned // PerCallContext implementation is wrong. private readonly Guid _key = Guid.NewGuid(); public override object GetValue() { return HttpContext.Current.Items[_key]; } public override void SetValue(object newValue) { HttpContext.Current.Items[_key] = newValue; } public override void RemoveValue() { var obj = GetValue(); HttpContext.Current.Items.Remove(obj); } } </code></pre> <p>Be aware that Unity will not dispose context for you. Also be aware that default <code>UnityContainer</code> implementation will never call <code>RemoveValue</code> method. </p> <p>If your implementation resolves all repositories in single <code>Resolve</code> call (for example if your controllers receives instances of repositories in constructor and you are resolving controllers) you don't need this lifetime manager. In such case use build-in (Unity 2.0) <code>PerResolveLifetimeManager</code>. </p> <p><strong>Edit:</strong></p> <p>I see pretty big problem in your provided configuration of <code>UnityContainer</code>. You are registering both repositories with <code>ContainerControllerLifetimeManager</code>. This lifetime manager means Singleton instance per container lifetime. It means that both repositories will be instantiated only once and instance will be stored and reused for subsequent calls. Because of that it doesn't matter what lifetime did you assign to <code>MyEntities</code>. It is injected to repositories' constructors which will be called only once. Both repositories will use still that single instance of <code>MyEntities</code> created during their construction = they will use single instance for whole lifetime of your <code>AppDomain</code>. That is the worst scenario you can achieve.</p> <p>Rewrite your configuration this way:</p> <pre><code>var container = new UnityContainer(); container .RegisterType&lt;ProductsRepository&gt;() .RegisterType&lt;CategoryRepository&gt;() .RegisterType&lt;MyEntities&gt;(new PerResolveLifetimeManager(), dbConnectionString); </code></pre> <p>Why this is enough? You are resolving controller which is dependent on repsitories but no repository instance is needed more then once so you can use default <code>TransientLifetimeManager</code> which will create new instance for each call. Because of that repository constructor is called and <code>MyEntities</code> instance must be resolved. But you know that multiple repositories can need this instance so you will set it with <code>PerResolveLifetimeManager</code> => each resolving of controller will produce only one instance of <code>MyEntities</code>.</p>
    singulars
    1. This table or related slice is empty.
    1. POMVC, EF - DataContext singleton instance Per-Web-Request in Unity
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USCommunity
    1. USLadislav Mrnka
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POMVC, EF - DataContext singleton instance Per-Web-Request in Unity
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. CO@Ladislav - thank you for your reply. My real problem is actually concerning working with multiple ObjectContext instances, because of the structure of my repositories. Initially, each repo was operating on their own ObjectContext instance (within the Using() statement), but this caused some troubles. See also the issue and soultion with Single ObjectContext for each request here: [link](http://dotnetslackers.com/articles/ado_net/Managing-Entity-Framework-ObjectContext-lifespan-and-scope-in-n-layered-ASP-NET-applications.aspx)
      singulars
      1. PO
      1. USNima
    2. CO@Ladislav : regarding UNITY, thanks for your suggestion. I will use that instead of CallContext (havn't figured out the difference between those). Regarding disposing an ObjectContext instance after the request is finished, how is this done? Should I go for the Application_EndRequest event as described here [link](http://stackoverflow.com/questions/2482220/attaching-linq-to-sql-datacontext-to-httpcontext-in-business-layer)?
      singulars
      1. PO
      1. USNima
    3. CO@Nima: Using single `ObjectContext` per request is correct approach. There should not be big difference between `CallContext` and `HttpContext` implementation because it is most probably stored in `CallContext`. Disposing context is tricky. I'm doing it in controller factory. In `ReleaseController` I dispose controller and it in turns releases its dependencies.
      singulars
      1. PO
      1. USLadislav Mrnka
 

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