C#分布式事务解决方案-TransactionScope

引用一下别人的导读:在实际开发工作中,执行一个事件,然后调用另一接口插入数据,如果处理逻辑出现异常,那么之前插入的数据将成为垃圾数据,我们所希望的是能够在整个这个方法定义为一个事务,TransactionScope 类提供一个简单方法,通过这一方法,您不必与事务本身交互,即可将代码块标记为参与某个事务。TransactionScope对象创建了一个事务,同时将该事务设置给Transaction类的Current属性。

一、TransactionScope的优点
1、使用起来比较方便.TransactionScope可以实现隐式的事务,使你可以在写数据访问层代码的时候不用考虑到事务,而在业务层的控制事务.
2、可以实现分布式事务,比如跨库或MSMQ.

二、TransactionScope缺点
1、性价比不高.比如,你只是在"Scope"里控制一个库的事务.用"TransactionScope"就有点浪费了.
2、一般情况下只要你使用"TransactionScope",都要配置MSDTC,要配防火墙,要开139端口.这个端口不可以更改

三、如果你不得不用分布式事务,那也得琢磨琢磨
1.这步操作一定得在事务当中吗?这步操作如果没完成或者失败了,值得回滚整个事务吗?难道没有优雅的补偿措施或者容错措施?
2.分布式事务涉及到的点,必须的这么多?必须得实时的操作这一大串?不能通过通知类操作去精简掉某些点?
3.在发起分布式事务之后,你是不是做了事务无关的操作,尽管这些操作跟事务无关?(如,读取数据、计算、等用户返回消息、等其他模块的调用返回等等)要知道事务应该尽快结束。
4.你没有把一些读操作也算在事务里面了吧?这是很容易犯的错误,你在事务中Enlist了一个select 操作。
5.你的操作,某些步骤可以等全部操作完成之后再执行.这类操作具有明显的通知类特点。通知类操作是说,我给你一个通知,并且我保证通知到了你;你必须吃下这个通知,并且保证处理成功,但是你不必我一通知你你就处理。这样的操作很明显可以用另外一个任务去搞。

四、使用分布式事务注意如下几点
1:确保参与事务的machine开启了分布式事务支持;
2:如果machine开启了防火墙,需要设置msdtc进程为例外;
3:参与事务的machine不能跨域(如果跨域,目前微软还没有确切的解决方案);
4:多数据库时才使用分布式事务,如果是同一个数据库,最好使用SqlTransaction.

1、先添加System.Transactions的引用(需要添加Net程序集)

C#调用时的代码如下:

对此分布式事务类讲解的很清晰的blogs地址:http://www.cnblogs.com/artech/archive/2010/01/31/1660356.html

using System.Transactions;
using (TransactionScope scope = new TransactionScope())
{
    //trancation one do something...
    var dbo1 = DBFactory.GetDBFacade(DBConnectionStringName.YSL_BusinessTravelTrade_ReadWrite);
    string sql1 = "UPDATE dbo.TestUser SET name=‘ccc‘ WHERE id = 2";
    dbo1.ExecuteNonQuery(CommandType.Text, sql1);
    //trancation two do something...
    var dbo = DBFactory.GetDBFacade(DBConnectionStringName.YSL_BusinessTravel_ReadWrite);
    string sql = "UPDATE dbo.TestUser SET name=‘ccc‘ WHERE id = 2";
    dbo.ExecuteNonQuery(CommandType.Text, sql);
    //submit
    scope.Complete();
}

2、设置web服务器及sql服务器环境配置

控制面板->系统和安全->管理工具->组件服务(WEB服务器和SQL服务器都需要配置此项)

控制面板->系统和安全->管理工具->服务(WEB服务器和SQL服务器都需要配置此项)

控制面板->系统和安全->Windows防火墙(WEB服务器和SQL服务器都需要配置此项)

3、MSSQL配置

对服务器连接,右键->属性

4、配置Hosts(只配置WEB服务器即可,如果不行,在SQL服务器上也配置上)

C:\Windows\System32\drivers\etc
hosts文件,用记事本打开(在WEB服务器上的Hosts文件中需要配置SQL服务器的信息)(如果测试通不过,在SQL服务器上的Hosts文件中配置上WEB服务器的信息)

时间: 2024-08-09 10:35:41

C#分布式事务解决方案-TransactionScope的相关文章

分布式事务 解决方案

事务的概念来源于业务过程.在许多情况下我们都希望能够确保在一个过程中执行的所有操作是完全成功的.在集中式系统中,事务被广泛用于服务器端和数据库系统,控制数据的操作.随着分布式计算的发展,事务在分布式计算领域中也得到了广泛的应用,但是分布式系统架构中,分布式事务问题是一个绕不过去的挑战.而微服务架构的流行,让分布式事问题日益突出! 下面我们以电商购物支付流程中,在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析! 如上图所示,假设三大参与平台(电商平台.支付平台.银行)的系统都做了分布

基于金融系统的分布式事务解决方案

分布式系统架构中,分布式事务问题是一个绕不过去的挑战.而微服务架构的流行,让分布式事问题日益突出! 下面我们以电商购物支付流程中,在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析! 如上图所示,假设三大参与平台(电商平台.支付平台.银行)的系统都做了分布式系统架构拆分,按上数中的流程步骤进行分析: 1.电商平台中创建订单:预留库存.预扣减积分.锁定优惠券,此时电商平台内各服务间会有分布式事务问题,因为此时已经要跨多个内部服务修改数据: 2.支付平台中创建支付订单(选银行卡支付):查

微服务架构的分布式事务解决方案

微服务架构的分布式事务解决方案 标签:分布式事务,微服务,消息最终一致性,分布式事务解决方案发布于 2016-07-16 18:39:05 分布式系统架构中,分布式事务问题是一个绕不过去的挑战.而微服务架构的流行,让分布式事问题日益突出! 下面我们以电商购物支付流程中,在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析! 如上图所示,假设三大参与平台(电商平台.支付平台.银行)的系统都做了分布式系统架构拆分,按上数中的流程步骤进行分析: 1.电商平台中创建订单:预留库存.预扣减积分.

java微服务架构的分布式事务解决方案

java微服务架构的分布式事务解决方案 课程目录如下: 1.课程介绍20分钟2.解决方案的效果演示(结合支付系统真实应用场景)45分钟3.常用的分布式事务解决方案介绍47分钟4.消息发送一致性(可靠消息的前提保障)20分钟5.消息发送一致性的异常流程处理16分钟6.常规MQ队列消息的处理流程和特点12分钟7.消息重复发送问题及业务接口的幂等性设计18分钟8.可靠消息最终一致性方案1(本地消息服务)的设计19分钟9.可靠消息最终一致性方案2(独立消息服务)的设计24分钟10.可靠消息服务的设计与实

分布式事务解决方案---阅读--篇1--关于分布式系统的数据一致性问题

self: 这篇文章逻辑不算很清晰,但讲到的点还算是比较好的.自己总结一下可以做不错的参考: 1. 这边文章主要讲了两个方面,一方面是MQ的消息可靠性问题,另一方面是MQ可以被利用来做补偿机制的最终一致性分布式事务解决方案. 2. 关于MQ消息的问题大致有下面三个 2.1 如何保证A->M的消息,M一定接收到了,同样,如何保证M->A的消息,M一定接收到了 2.2 如果数据需要一致性更新,比如A发送了三条消息给M,M要么全部保存,要么全部不保存,不能够只保存其中的几条记录.我们假设更新的数据是

微服务架构下分布式事务解决方案——阿里云GTS

https://blog.csdn.net/jiangyu_gts/article/details/79470240 1 微服务的发展 微服务倡导将复杂的单体应用拆分为若干个功能简单.松耦合的服务,这样可以降低开发难度.增强扩展性.便于敏捷开发.当前被越来越多的开发者推崇,很多互联网行业巨头.开源社区等都开始了微服务的讨论和实践.Hailo有160个不同服务构成,NetFlix有大约600个服务.国内方面,阿里巴巴.腾讯.360.京东.58同城等很多互联网公司都进行了微服务化实践.当前微服务的开

分布式事务解决方案

分布式理论 当我们的单个数据库的性能产生瓶颈的时候,我们可能会对数据库进行分区,这里所说的分区指的是物理分区,分区之后可能不同的库就处于不同的服务器上了,这个时候单个数据库的ACID已经不能适应这种情况了,而在这种ACID的集群环境下,再想保证集群的ACID几乎是很难达到,或者即使能达到那么效率和性能会大幅下降,最为关键的是再很难扩展新的分区了,这个时候如果再追求集群的ACID会导致我们的系统变得很差,这时我们就需要引入一个新的理论原则来适应这种集群的情况,就是 CAP 原则或者叫CAP定理,那

分布式事务解决方案——柔性事务与服务模式

在分布式系统中,是无法使用本地事务保证数据的一致性的.一种标准的分布式事务就是全局事务(DTP模型).他是基于2PC来控制的.但是由于2PC自身就存在同步阻塞的问题,这也就导致全局事务效率很低.所以,这种全局事务并不适合解决大型网站的分布式事务问题. 柔性事务在业内,主要用来解决分布式事务的方案是使用柔性事务.所谓柔性事务,相比较与数据库事务中的ACID这种刚性事务来说,柔性事务保证的事"基本可用,最终一致."这其实就是基于BASE理论,保证数据的最终一致性. 虽然柔性事务并不像刚性事

阿里微服务架构下分布式事务解决方案-GTS

虽然微服务现在如火如荼,但对其实践其实仍处于初级阶段.即使互联网巨头的实践也大多是试验层面,鲜有核心业务系统微服务化的案例.GTS是目前业界第一款,也是唯一的一款通用的解决微服务分布式事务问题的中间件,而且可以保证数据的强一致性.本文将对GTS做出深入解读. 微服务倡导将复杂的单体应用拆分为若干个功能简单的.松耦合的服务,这样可以降低开发难度.增强扩展性.便于敏捷开发.概念2012年提出迅速火遍全球,被越来越多的开发者推崇,很多互联网行业巨头.开源社区等都开始了微服务的讨论和实践.根据Netfl