c# – 事务死锁,如何设计正确?
所以我正在研究这个实体框架项目,这个项目将被用作DAL,当运行压力测试(通过Thread()启动实体的几个更新)时,我得到这些:
以下是我如何实现我的类的方法的一些例子: public class OrderController { public Order Select(long orderID) { using (var ctx = new BackEndEntities()) { try { var res = from n in ctx.Orders .Include("OrderedServices.Professional") .Include("Agency") .Include("Agent") where n.OrderID == orderID select n; return res.FirstOrDefault(); } catch (Exception ex) { throw ex; } } } public bool Update(Order order) { using (var ctx = new BackEndEntities()) { try { order.ModificationDate = DateTime.Now; ctx.Orders.Attach(order); ctx.SaveChanges(); return true; } catch (Exception ex) { throw ex; } } } } 和: public class AgentController { public Agent Select(long agentID) { using (var ctx = new BackEndEntities()) { try { var res = from n in ctx.Agents.Include("Orders") where n.AgentID == agentID select n; return res.FirstOrDefault(); } catch (Exception ex) { throw ex; } } } public bool Update(Agent agent) { using (var ctx = new BackEndEntities()) { try { agent.ModificationDate = DateTime.Now; ctx.Agents.Attach(agent); ctx.ObjectStateManager.ChangeObjectState(agent,System.Data.EntityState.Modified); ctx.SaveChanges(); return true; } catch (Exception ex) { throw ex; } } } } 显然,这里的代码可能会更好,但我更喜欢EF新手.但我认为我的问题是上下文的设计问题. 我记得有人在这里提到,如果我的上下文不共享,我不会遇到这些死锁问题. 这对我来说似乎并不“共享”,因为我在每个方法中使用新的BackEndEntities(),所以我必须改变什么才能使其更加健壮? 这个DAL将用于在互联网上暴露的Web服务(在coure的代码审查之后),所以我无法控制多少会受到压力,许多不同的实例可能想要更新同一个实体. 谢谢! 解决方法
僵局自由在一个大系统中是一个非常困难的问题.它与EF本身无关.
缩短事务的使用寿命可以减少死锁,但会导致数据不一致.在你以前死锁的地方,你现在正在破坏数据(没有任何通知). 因此,根据逻辑事务选择您的上下文生命周期和事务生命周期,而不是根据物理考虑. 打开快照隔离.这需要完全超出等式的阅读交易. 对于编写交易,您需要找到锁定订单.通常情况下,最简单的方法就是将悲观情绪锁定在更高层次上.示例:您是否始终在客户的上下文中修改数据?以该客户的更新锁作为交易的第一个声明.通过序列化对该客户的访问来提供完全的死锁自由. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |