EF架构~关系表插入应该写在事务里,但不应该是分布式事务

简介:

这个标题很有意思,关系表插入,就是说主表和外表键在插入时,可能会有同步插的情况,如在建立主表时,扩展表需要同步完成数据的初始化工作,而对于多表插入时,我们为了保证数据的一致性会针它写在事务中,而对于.net中的事件,它在一些情况下,会不那么单纯,对于ef和linq to sql来说,你的事务如果出现多次提交动作(submitchange | savechanges),那么,.net这边会把它提升为分布式事务(MSDTC),即.net认为,对于一个数据表的操作,不会出现多个savechanges,OK,这个可以解释的通,一个数据库,一个提交,这是符合性能要求的,呵呵,但对于我们的架构来说,有时一疏忽,就违背了.net的这个原则,如,我们封装的Insert方法,可能是这样的

   public virtual void Insert(TEntity item)
        {
       
            Db.Entry<TEntity>(item);
            Db.Set<TEntity>().Add(item);
            this.SaveChanges();
           
        }

这个代码也没有问题,在一个插入动作完成后,系统由SaveChanges方法完成一次提交,正是由于这样的代码,所以我们的麻烦就来了,如果是对两个表的操作吗?

aRepository.Insert(a);
bRepository.Insert(b);

什么问题?数据一致性不能保证,因为没有事务块,呵呵,加上了再看看

  using (TransactionScope trans = new TransactionScope())
{
  aRepository.Insert(a);
  bRepository.Insert(b);
  trans.Commit();
}

OK,感觉是没有问题了,但细一想就会看出问题来了,因为我们封装的insert会有提交动作,所以,在这个事务块中,.net会被认识是一个MSDTC(分布式的事务),原因是提交了多次,而如果你没有打开msdtc服务的话,就会出现下面的黄屏了

注意:系统触发分布式事务的前提是你的WEB服务器与数据库服务器分别部署在两个服务器上,一台不会出现这个问题的。

OK,这个MSDTC是怎么一回事,不是今天要说的重要,如果想学习MSDTC,请看我的这些文章:

 

第二十六回   将不确定变为确定~transactionscope何时提升为分布式事务?

第二十七回   将不确定变为确定~transactionscope何时提升为分布式事务~续

第二十八回   将不确定变为确定~transactionscope何时提升为分布式事务~再续(避免引起不必要的MSDTC)

第二十九回    将不确定变为确定~transactionscope何时提升为分布式事务~大结局

今天我们要说的是在插入关系表时,怎样使它不被提升为分布式事务,事实上,怎么做我们已经知道了,就是方法中只出现一个savechages,呵呵,而对于主表与扩展表来说,对于自增主键的主表,做起来就有些麻烦了,呵呵,我们还需要借助SQL函数来实现主键的获取工作,当主键插入后,通过SQL函数得到新值,然后再为扩展表赋值,最后一些savechange()就可以了,具体我们看一下代码:

  int maxID = Convert.ToInt32(new TsingDa_NewLearningBarEntities()//当前表最大ID
                  .Database.SqlQuery<decimal>("SELECT IDENT_CURRENT ('Classroom_Info')")
                  .First());
            using (TransactionScope trans = new TransactionScope())
            {
                try
                {
                    db.Entry<Classroom_Info>(entity);
                    db.Set<Classroom_Info>().Add(entity);

                    //绑定学生
                    entity.User_Classroom_R.ToList().ForEach(i =>
                    {
                        i.ClassroomInfoID = maxID + 1;
                        db.Entry<User_Classroom_R>(i);
                        db.Set<User_Classroom_R>().Add(i);
                    });
                    db.SaveChanges();//是否为msdtc就看它提交的次数
                    trans.Complete();
                }
                catch (Exception)
                {
                    trans.Dispose();//出现异常,事务手动释放
                    throw;
                }
            }

而一次savechanges所产生的SQL也是我们可以接受的,与服务器连接池中开启一个新连接,然后把语句一条一条的发过去,虽然不是一次性发送,但结果我们也是可以接受的,呵呵。

 

补充回复:

看了xiashengwang的 回复,我自己去试了一下,果然savechange将当前上下文中所有要提交的东西包在了一个事务块里,出现异常后,自动完成callback,所以,对 于一个数据库来说TransactionScope可以省去,而对于多个数据库的操作,才需要使用TransactionScope,而对于何时将 TransactionScope提升为MSDTC的级别,到目前为止,我只能说,一个上下文的savechanges不会提升,多个 savechanges就会提升到msdtc,而矛盾是,一个savechanges的话,确实不需要外加TransactionScope块了,呵呵, 这部分文章估计我还要继续写了,看看有没有办法在同一上下文多个savechanges操作时,不让系统提升到MSTDC的级别,呵呵。

本文转自博客园张占岭(仓储大叔)的博客,原文链接:EF架构~关系表插入应该写在事务里,但不应该是分布式事务,如需转载请自行联系原博主。

目录
相关文章
|
13天前
|
SQL 关系型数据库 MySQL
乐观锁在分布式数据库中如何与事务隔离级别结合使用
乐观锁在分布式数据库中如何与事务隔离级别结合使用
|
10天前
|
存储 JSON 数据库
Elasticsearch 分布式架构解析
【9月更文第2天】Elasticsearch 是一个分布式的搜索和分析引擎,以其高可扩展性和实时性著称。它基于 Lucene 开发,但提供了更高级别的抽象,使得开发者能够轻松地构建复杂的搜索应用。本文将深入探讨 Elasticsearch 的分布式存储和检索机制,解释其背后的原理及其优势。
39 5
|
29天前
|
存储 NoSQL Java
一天五道Java面试题----第十一天(分布式架构下,Session共享有什么方案--------->分布式事务解决方案)
这篇文章是关于Java面试中的分布式架构问题的笔记,包括分布式架构下的Session共享方案、RPC和RMI的理解、分布式ID生成方案、分布式锁解决方案以及分布式事务解决方案。
一天五道Java面试题----第十一天(分布式架构下,Session共享有什么方案--------->分布式事务解决方案)
|
24天前
|
机器学习/深度学习 分布式计算 Cloud Native
云原生架构下的高性能计算解决方案:利用分布式计算资源加速机器学习训练
【8月更文第19天】随着大数据和人工智能技术的发展,机器学习模型的训练数据量和复杂度都在迅速增长。传统的单机训练方式已经无法满足日益增长的计算需求。云原生架构为高性能计算提供了新的可能性,通过利用分布式计算资源,可以在短时间内完成大规模数据集的训练任务。本文将探讨如何在云原生环境下搭建高性能计算平台,并展示如何使用 PyTorch 和 TensorFlow 这样的流行框架进行分布式训练。
43 2
|
24天前
|
监控 Java 开发者
随着软件开发的发展,传统单体应用已难以适应现代业务需求,微服务架构因此兴起,成为构建可伸缩、分布式系统的主流
随着软件开发的发展,传统单体应用已难以适应现代业务需求,微服务架构因此兴起,成为构建可伸缩、分布式系统的主流。本文探讨Java微服务架构的设计原则与实践。核心思想是将应用拆分为独立服务单元,增强模块化与扩展性。Java开发者可利用Spring Boot等框架简化开发流程。设计时需遵循单一职责、自治性和面向接口编程的原则。以电商系统为例,将订单处理、商品管理和用户认证等拆分为独立服务,提高可维护性和容错能力。还需考虑服务间通信、数据一致性及监控等高级话题。掌握这些原则和工具,开发者能构建高效、可维护的微服务应用,更好地应对未来挑战。
63 1
|
1月前
|
Cloud Native 云计算 微服务
云原生时代:企业分布式应用架构的惊人蜕变,从SOA到微服务的大逃亡!
【8月更文挑战第8天】在云计算与容器技术推动下,企业分布式应用架构正经历从SOA到微服务再到云原生的深刻变革。SOA强调服务重用与组合,通过标准化接口实现服务解耦;微服务以细粒度划分服务,增强系统灵活性;云原生架构借助容器化与自动化技术简化部署与管理。每一步演进都为企业带来新的技术挑战与机遇。
77 6
|
11天前
|
Java 数据库连接 微服务
揭秘微服务架构下的数据魔方:Hibernate如何玩转分布式持久化,实现秒级响应的秘密武器?
【8月更文挑战第31天】微服务架构通过将系统拆分成独立服务,提升了可维护性和扩展性,但也带来了数据一致性和事务管理等挑战。Hibernate 作为强大的 ORM 工具,在微服务中发挥关键作用,通过二级缓存和分布式事务支持,简化了对象关系映射,并提供了有效的持久化策略。其二级缓存机制减少数据库访问,提升性能;支持 JTA 保证跨服务事务一致性;乐观锁机制解决并发数据冲突。合理配置 Hibernate 可助力构建高效稳定的分布式系统。
25 0
|
14天前
|
架构师 NoSQL 中间件
挑战架构师极限:分布式锁的四种实现方式,优劣对比让你一目了然!
【8月更文挑战第29天】在2024年软考架构师考试中,掌握分布式锁的实现方法极其重要。本文详细介绍了基于数据库、Redis及ZooKeeper三种常见分布式锁方案。数据库锁简单易懂但性能低;Redis锁性能优越且支持自动续期,但需引入中间件;ZooKeeper锁可靠性高,适用于分布式环境,但实现复杂。通过对比各方案优缺点,帮助考生更好地应对考试,选择最适合业务场景的分布式锁策略。
24 0
|
1月前
|
存储 监控 安全
|
2月前
|
NoSQL 算法 Java
(十三)全面理解并发编程之分布式架构下Redis、ZK分布式锁的前世今生
本文探讨了从单体架构下的锁机制到分布式架构下的线程安全问题,并详细分析了分布式锁的实现原理和过程。

热门文章

最新文章