Nolock 作为 EF4 每个请求创建一个 ObjectContext 的默认值
此代码是否有任何副作用：
///This code runs per request
public static MyObjectContext CreateEntity()
{
MyObjectContext db=new MyObjectContext();
db.Connection.Open();
var con = (SqlConnection)((EntityConnection)hi.Connection).StoreConnection;
SqlCommand cmd = new SqlCommand("set transaction isolation level read uncommitted",con);
cmd.ExecuteNonQuery();
return db;
}
现在“db”实例将运行 ReadUncommited 模式？
Is there any side effect for this code:
///This code runs per request
public static MyObjectContext CreateEntity()
{
MyObjectContext db=new MyObjectContext();
db.Connection.Open();
var con = (SqlConnection)((EntityConnection)hi.Connection).StoreConnection;
SqlCommand cmd = new SqlCommand("set transaction isolation level read uncommitted",con);
cmd.ExecuteNonQuery();
return db;
}
Now "db" instance will run ReadUncommited mode?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
副作用是您必须手动处理连接，并且连接在其整个生命周期内由上下文保存。它还在上下文的整个生命周期中保持打开状态，这可能会降低效率。
另一个副作用是读取未提交的隔离级别本身，使用它非常危险，因为它允许读取未提交的事务数据。
为什么需要这个？ EF默认使用数据库服务器默认的事务隔离模式。对于 SQL Server，它是读提交的。默认情况下，EF 也不持有记录锁定，因为每个读取操作只是事务的一部分，其持续时间仅针对该读取。只有
SaveChanges对多个数据库命令使用事务。The side effect is that you must handle your connection manually and that the connection is held by the context for whole its lifetime. It is also kept opened for the whole lifetime of the context which can be less efficient.
Another side effect is read uncommited isolation level itself which is quite dangerous to use because it allows reading uncommited transactional data.
Why do you need this? EF by default uses default transaction isolation mode of the database server. For SQL server it is read commited. EF also by default doesn't hold locks on records because each read operation is only part of a transaction with duration just for that read. Only
SaveChangesuses transaction for multiple database commands.