Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
We have a static class library to deal with repeated multi-contextual tasks. Is it bad practice to create an EF db context as member of a static class?
DB contexts are meant to be disposed of for a reason. Having them disposed frequently keeps the connection pool “flowing” and probably (here I’m speculating) assures that tables don’t remain locked.
So am I inviting trouble having a db context in a static class or am I overthinking this?
IMO this is definitally not something you want to be doing.
Locking isn’t actually the main problem you are going to have here. EF will only lock for the duration of a save changes call (its actually one of the big benefits of using a tracking graph over partially committed transactions which most other ORMs use).
What is going to cause you greif is the tracking graph itself. How EF works (in most cases) is that it keeps a copy of every entity its ever seen and loops through them to find whats changed and run a process called fixups which makes navigation properties work with backlinks. This process loops through every entity the context has ever seen and is called on a bunch of operations (add, attach, delete, save, query and a few others). This means if the tracking graph is large, this process can take quite a bit of time. If you keep your context alive forever the tracking graph size tends toward the size of your database, making it unwieldy and slow.