There is an unsaved comment in progress. You will lose your changes if you continue. Are you sure you want to reopen the work item?

38

Closed

Allow DbContext to be created with an already-open existing connection plus ensure connection closing is consistent with opening

description

DbContext can only be created with a closed connection, there are scenarios where it would be helpful if the connection could be open when creating the context (such as sharing a connection between components where we can not guarantee the state of the
connection).

The state of the EntityConnection and DbConnection should also be kept in sync.

This item was migrated from the DevDiv work item tracking system [ID=7992].

Pease also consider the following scenario. A model-centric application is built around a public, “customer-owned” entity model using the EF model-first approach. It primarily deals with the entities defined in the model (e.g. Products, Suppliers, Orders,
and so on). The core data processing is performed by means of ObjectContext. There are some supporting facilities in the application, however, which require their data to be stored in the same database and even within the transactions originated in the core
data layer (e.g. diagnostic/audit logs, license checks and so on). The data structures for those facilities should not (and cannot) be declared in the main entity model. Moreover it makes much more sense to build those facilities using EF code-first approach
(DbContext), since their data are just a serialized state of their run-time objects and the program code is the central design/maintenance aspect in this case (not the data model).

Currently, for this to work, a separate connection has to be made each time some DbContext-based facility needs to participate in the core transaction. Besides the inconvenience of re-establishing a connection by borrowing all its settings instead of re-using
the connection itself, it leads to promoting the transaction to distributed and thus to those infamous “DTC not available” problem in (the most usual) case of a single database/server.
Given this scenario, a seamless connection transitioning between ObjectContext and DbContext is badly needed. Any cooperation on this (real) scenario goes without saying.

Checked in change #56e510c. Updated EntityConnection State so it now tracks the underlying store connection State. This is a breaking change as we will now report a different (but more consistent) state for the EntityConnection.