StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<blockquote> <p>... issues ... regards to multiple EF applications hitting the same database server?</p> </blockquote> <p>Rewind a bit to the fact that your application is an ASP .NET MVC based application. Having multiple instances of it is probably going to raise the spectre of state management.</p> <p>MSDN has a pretty good introduction to <a href="http://msdn.microsoft.com/en-us/library/ms178581%28v=vs.100%29.aspx" rel="nofollow">why this is an issue</a>:</p> <blockquote> <p>HTTP is a stateless protocol. This means that a Web server treats each HTTP request for a page as an independent request. The server retains no knowledge of variable values that were used during previous requests. ASP.NET session state identifies requests from the same browser during a limited time window as a session, and provides a way to persist variable values for the duration of that session. By default, ASP.NET session state is enabled for all ASP.NET applications.</p> <p>Alternatives to session state include the following:</p> <ul> <li>Application state, which stores variables that can be accessed by all users of an ASP.NET application.</li> </ul> </blockquote> <p>This point is an extremely common way of storing state, but breaks down when there's multiple instances of an application involved (the state is "visible" to only one of the instances).</p> <p>Typically this is worked around by using either the <code>StateServer</code> or <code>SQLServer</code> value of <code>SessionStateMode</code>. The same article provides a pretty good summary of each option (emphasis mine).</p> <blockquote> <ul> <li><p><code>StateServer</code> mode, which stores session state in a separate process called the ASP.NET state service. This ensures that session state is preserved if the Web application is restarted <strong>and also makes session state available to multiple Web servers in a Web farm</strong>.</p></li> <li><p><code>SQLServer</code> mode stores session state in a SQL Server database. This ensures that session state is preserved if the Web application is restarted <strong>and also makes session state available to multiple Web servers in a Web farm</strong>.</p></li> </ul> </blockquote> <p>If your application is stateless, this is a moot point.</p> <blockquote> <p>I am worrying I made the wrong choice by choosing EF </p> </blockquote> <p>As far as issues with multiple instances of your application accessing a database go, you're going to have issues with any sort of data access technology.</p> <p>Here's the basic scenario: let's say your application sends welcome emails to users on a schedule.</p> <p>Given the table <code>Users</code>:</p> <pre><code>UserId | Email | WelcomeLetterSent -------+-----------------+------------------ 1 | user@domain.com | 0 </code></pre> <p>And some psuedo-code:</p> <pre><code>foreach (var user in _context.Users.Where(u => !u.WelcomeLetterSent)) { SendEmailForUser(user); user.WelcomeLetterSent = true; } _context.SaveChanges(); </code></pre> <p>There's a <a href="http://en.wikipedia.org/wiki/Race_condition" rel="nofollow">race condition</a> where both instance one and instance two of your application might simultaneously evaluate <code>_context.Users.Where(...)</code> before either of them has the chance to set <code>WelcomeLetterSent = true</code> and call <code>SaveChanges</code>. In this case, two welcome emails might get sent to each user instead of one.</p> <p>Concurrency can be an insidious thing. There's a primer on managing concurrency with the Entity Framework over <a href="http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/handling-concurrency-with-the-entity-framework-in-an-asp-net-mvc-application" rel="nofollow">here</a>, but this is only the tip of the iceberg.</p> <p>The answer to your question? It depends on what your application does :)</p> <blockquote> <p>On top of that, I ideally want to build some "extra" support applications that hook in to the same DB... and, I am just not sure how EF will handle multiple apps to the same DB....</p> </blockquote> <p>If your application can tolerate multiple instances of itself accessing one database, then it's usually not a stretch to make these "support applications" play nicely. It's not much different whether the concurrency is from multiple instances of one application or multiple applications with one instance each.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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