This project is read-only.


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


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].
Closed Jan 19, 2013 at 12:18 AM by RoMiller
Checked in and verified


lajones wrote Nov 20, 2012 at 7:06 PM

Checked in some baseline tests to record the status of the EntityConnection vs the store connection as of now - #86c59d6

mzhg wrote Nov 23, 2012 at 2:12 PM

Using opened connection would be very useful when using EF with System.Data.SQLite.

This provider have a function "SetPassword" which allow to open encrypted database without putting the password into the connection string. This must to be call before Open().

I have found no way to use this function outside or inside my DbContext.
The only way is to include the password into the connection string.

I've tried to use SetPassword:
  • before the DbContext constructor: fail
  • after on mySQLiteConnection object: fail
  • after on dbContext.Database.Connection: fail
One thing could work, I need a callback (event) on the DbContext when EF open the connection (OnBeforeOpen) so I could call SetPassword here.


Dennis_Wanke wrote Nov 26, 2012 at 9:32 AM

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.

lajones wrote Nov 28, 2012 at 10:37 PM

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.

lajones wrote Nov 29, 2012 at 11:47 PM

Checked in change #6869eba. Couple of updates to tests and testing that StateChangeEvents are fired at the correct time.

lajones wrote Dec 5, 2012 at 10:35 PM

Changed sync mechanism to subscribe to events on underlying store connection. Commit #5d14eca.

lajones wrote Dec 5, 2012 at 11:01 PM

ANother small commit #1198350. Just to update an error message.

lajones wrote Dec 7, 2012 at 12:47 AM

@mzhg - I think this is outside the scope of this bug. However it is worth considering - there is an ongoing discussion about lifetime hooks in general here which you may want to join.

Dennis_Wanke wrote Dec 7, 2012 at 11:59 AM

The latest changes seem to comply with the scenario described below. Just make sure the current behavior is not changed until the official release.

RoMiller wrote Jan 19, 2013 at 12:18 AM

Checked in and verified