ajcvickers

user stats

Member SinceNovember 14, 2011
Last VisitNovember 21, 2014

Contact

developer for

Entity Framework

ajcvickers

personal statement

Developer at Microsoft working on the Entity Framework.
Twitter: @ajcvickers
Blog: http://blog.oneunicorn.com/

activity stream

November 17, 2014 - Entity Framework: Commented work item: Security hole in EF during migrations?

November 17, 2014 - Entity Framework: Pushed 4187b1c308316a22b38ef533b1409024bc0f7406, Fix for CodePlex 2579: Thread using Migrations can cause other threads to use wrong connection The root of the problem is that using DbMigrator causes change to app domain state through use of a static dictionary in DbContextInfo. This change in state can cause a context instance of a given type to get the wrong connection when a migrator is being used with that context type. In other words, the migrator changes static state so that any context instance of a given type used in the app domain will get the connection intended to be used for migrations. In the repro that state was not being cleaned up; the previous fix for this issue caused it to be cleaned up and so the other context in the repro code started getting the correct connection again. However, the code still transitions through this change in app domain state. So if some thread is using a migrator and some other thread starts a query while the migration is going on, then that second thread will use the wrong connection and return wrong data. I suspect that this is what is happening in the production system with the "long running queries", etc. The fix is to remove the static dictionary and set the context info for the current thread instead. This is similar to the code we have in EF7 for getting the service provider into the constructor without passing it--the issue is essentially the same since the context info is needed in the context constructor and yet is not passed into the constructor. I believe that thread static is fine here because there are no opportunities for async calls between setting the thread static and reading of the value. See https://entityframework.codeplex.com/workitem/1552 for the original issue.

November 17, 2014 - Entity Framework: Committed 4187b1c308316a22b38ef533b1409024bc0f7406, Fix for CodePlex 2579: Thread using Migrations can cause other threads to use wrong connection The root of the problem is that using DbMigrator causes change to app domain state through use of a static dictionary in DbContextInfo. This change in state can cause a context instance of a given type to get the wrong connection when a migrator is being used with that context type. In other words, the migrator changes static state so that any context instance of a given type used in the app domain will get the connection intended to be used for migrations. In the repro that state was not being cleaned up; the previous fix for this issue caused it to be cleaned up and so the other context in the repro code started getting the correct connection again. However, the code still transitions through this change in app domain state. So if some thread is using a migrator and some other thread starts a query while the migration is going on, then that second thread will use the wrong connection and return wrong data. I suspect that this is what is happening in the production system with the "long running queries", etc. The fix is to remove the static dictionary and set the context info for the current thread instead. This is similar to the code we have in EF7 for getting the service provider into the constructor without passing it--the issue is essentially the same since the context info is needed in the context constructor and yet is not passed into the constructor. I believe that thread static is fine here because there are no opportunities for async calls between setting the thread static and reading of the value. See https://entityframework.codeplex.com/workitem/1552 for the original issue.

November 13, 2014 - Entity Framework: Posted to discussion: How can I prevent the loading of ADO.net providers like OracleClient Data Provider when I only use Firebird?

November 13, 2014 - Entity Framework: Posted to discussion: Why is System.Web.Extensions.dll loaded when I call FirstOrDefault?

November 6, 2014 - Entity Framework: Modified work item: The EntityFramework.SqlServerCompact package does not install a release version of SQL Server Compact 4.0

November 6, 2014 - Entity Framework: Commented work item: The EntityFramework.SqlServerCompact package does not install a release version of SQL Server Compact 4.0

November 6, 2014 - Entity Framework: Pushed 80033a1bf3c4b8da0574dc2dd6f479f22c5b6211, SqlCe40ServicePack1CTP1 Fix for issue #2538

November 6, 2014 - Entity Framework: Committed 80033a1bf3c4b8da0574dc2dd6f479f22c5b6211, SqlCe40ServicePack1CTP1 Fix for issue #2538

November 6, 2014 - Entity Framework: Committed 80033a1bf3c4b8da0574dc2dd6f479f22c5b6211, SqlCe40ServicePack1CTP1 Fix for issue #2538

projects i'm following

forks

No forks.