- #Ef does not execute delete command update#
- #Ef does not execute delete command code#
- #Ef does not execute delete command windows#
Finally, we'll look in details at one strategy (among others) to manage the DbContext lifetime that addresses all the challenges presented above and that should work for most applications regardless of their complexity. We'll look at the pros and cons of several strategies commonly used to solve this problem. In this post, I'll go in depth into the various moving parts that are involved in DbContext lifetime management. Most of the common approaches suggested to manage DbContext instances don't work at all in this scenario. So the way we manage our DbContext instances must play well with multi-threading and parallel programming in general. Many services are heavily parallelized, either by taking advantage of async I/O or (more often) by simply distributing tasks across multiple threads via the TPL's Task.Run() or Parallel.Invoke() methods.But that's how the application was originally designed, it works very well and that's what we have to work with). (you may argue that there might be ways to redesign the whole system to avoid finding ourselves in this sort of situation. So in this application, a user action will often require us to execute multiple business transactions, which must be independently persisted.
#Ef does not execute delete command update#
when you've used the Facebook API to post a status update on Facebook, you can't roll it back even if that operation was part of a wider user action that eventually failed as a whole). Just because one remote API call failed doesn't mean that we can auto-magically "rollback" the results of any remote API call we may be done prior to the failed one (e.g.
Many of the articles I linked to make the assumption that "1 web request = 1 business transaction" that either gets committed or rolled back in an atomic manner (hence the idea of using a PerWebRequest-scope DbContext instance). Many user actions require us to make multiple remote API calls before we can return a result to the user. It relies heavily on third-party remote APIs, such as the Facebook, Twitter or LinkedIn APIs.Any approach assuming a single DbContext type won't work here. Its domain model is separated into several independent groups, each with their own DbContext type. It stores and reads data to / from multiple databases, including a main database, a secondary database, a reporting database and a logging database.Most of the articles I linked to above make the assumption that all services will execute within the context of a web request.
#Ef does not execute delete command windows#
It also includes many background services implemented as console apps and Windows Services, including a home grown task scheduler service and multiple services that process messages from MSMQ and RabbitMQ queues. The application is comprised of multiple web applications built with ASP.NET MVC and WebAPI.Here is for example an overview of the real-world application that prompted me to re-think the way we managed our DbContext instances:
To the point that certain features become impossible to implement or require to resort to increasingly complex structures or increasingly ugly hacks to work around the way the DbContext instances are created and managed. They also have the merit of being very simple - at least at first sight.įor certain types of applications however, the inherent limitations of these approaches pose problems. In fact, there is no shortage of articles discussing this topic.įor many applications, the solutions presented in those articles (which generally revolve around using a DI container to inject DbContext instances with a PerWebRequest lifetime) will work just fine. This isn't the first post that has been written about managing the DbContext lifetime in Entity Framework-based applications.
#Ef does not execute delete command code#
UPDATE: the source code for DbContextScope is now available on GitHub: DbContextScope on GitHub.
0 kommentar(er)
