CODEWITHSUNDEEP
asp.netasp.net-mvcasp.net-mvc-4entity-framework-4ado.net
chamara
chamara

Reputation: 12711

Managing large number of connections in Entity Framework

I'm using ASP.NET MVC 4 with Entity Framewwork database first approach. I normally do CURD operations in the following manner.

DashBordDataClassesDataContext context;

        public string Create(ProjectModel model)
        {
            string message = string.Empty;
            using (context = new DashBordDataClassesDataContext())
            {
                using (TransactionScope scopw = new TransactionScope())
                {
                    tblProject tb = new tblProject();
                    tb.ProjectName = model.ProjectName;
                    context.tblProjects.InsertOnSubmit(tb);
                    Save();
                }
            }

            return message;
        }

Recently I met a system architecture and he went through my code and raised the question below, to which I could't provide a proper answer.

"How will you manage the connections when there are potentially larger number of users running the same Create method?"

He suggested to share a single connection among multiple users.

I want to know that whether his solution is a practical or not

Upvotes: 1

Views: 745

Answers (2)

Laurent Lequenne
Laurent Lequenne

Reputation: 902

Kill your system architect :=) And do never share connection, or use a Static DbContext !

Upvotes: 0

Tony Hopkinson
Tony Hopkinson

Reputation: 20320

.Net by default uses connection pooling. When a connection goes out of scope, it gets passed back to the pool to be reused. The entire thing is built around this concept, and you have to go out of your way to do something different.

In other words ms does all this for you, so you don't have to worry about it in your code.

Sharing a connection between multiple users causes more problems than it solves. For instance how would you have more than one transaction scope on the same connection at the same time? Different trans-isolations will also be a problem, before you know where you are at, you have several different types of connection going and you are in world of hurt writing a lot of code to work against a framework specifically designed to cope with this issue.

The number of connections, how long they stay alive, etc is configurable. I've only had to fight it twice. Once in an installer, and once to cope with supporting sql server 2000 to 2010.

This does assume (as the EF framework does) that you are not hanging on to stuff. e.g all connection objects are instantiated via a using statement, so they get disposed of as soon as they are done with.

Upvotes: 3

Related Questions