在Asp.Net中的几种事务处理的方法

数据库层事务：效果最佳

CREATE PROCEDURE dbo.SPTransaction
    (
@UpdateID int,
@UpdateValue nchar(50),
@InsertID int,
@InsertValue nchar(50)
    )
AS
begin Tran
Update Region  Set RegionDescription=@UpdateValue where RegionID=@UpdateID

insert into Region Values (@InsertID,@InsertValue)

declare @RegionError int
select @RegionError=@@error
if(@RegionError=0)
COMMIT Tran
else
ROLLBACK Tran
GO

 

2 ADO.net事务 SqlTransaction
Ado.net事务可能是大家一般都用的
优点：简单，效率和数据库事务差不多。
缺点：事务不能跨数据库，只能在一个数据库连接上。如果是两个数据库上就不能使用该事务了。
Demo:

SqlConnection conn = new SqlConnection("Data Source=127.0.0.1;Initial Catalog=Northwind;Persist Security Info=True;User ID=sa;Password=123;");
SqlCommand cmd = new SqlCommand();
cmd.Transaction = conn.BeginTransaction();
cmd.ExecuteNonQuery();
cmd.Transaction.Commit();
cmd.Transaction.Rollback();

3 TransactionScope事务
TransactionScope事务类，它可以使代码块成为事务性代码。并自动提升为分布式事务
优点：实现简单，同时能够自动提升为分布式事务

Demo:

SqlConnection conn = new SqlConnection("Data Source=127.0.0.1;Initial Catalog=Northwind;Persist Security Info=True;User ID=sa;Password=123;");
SqlCommand cmd = new SqlCommand();
using (System.Transactions.TransactionScope ts = new TransactionScope())
{
   cmd1.ExecuteNonQuery();
   cmd2.ExecuteNonQuery();
   ts.Complete();
}

4 COM+事务
在分布式应用程序中，往往要同时操作多个数据库，使用数据库事务就不能满足业务的要求了。在COM+中，提供完整的事务处理服务。很方便处理多个数据库上的事务。
Demo:

SqlConnection conn = new SqlConnection("Data Source=127.0.0.1;Initial Catalog=Northwind;Persist Security Info=True;User ID=sa;Password=123;");
SqlCommand cmd = new SqlCommand();
ServiceConfig sc = new ServiceConfig();
//指定事务类型
sc.Transaction = TransactionOption.Required;
//设置启动跟踪
sc.TrackingEnabled = true;
//创建一个上下文，该上下文的配置由作为 cfg 参数传递的 ServiceConfig 对象来指定。
//随后，客户端和服务器端的策略均被触发，如同发生了一个方法调用。
//接着，新的上下文被推至上下文堆栈，成为当前上下文
ServiceDomain.Enter(sc);
cmd.ExecuteNonQuery();
//提交事务
ContextUtil.SetComplete();
ContextUtil.SetAbort();
ServiceDomain.Leave();

ContextUtil事务处理可以关联PageLoad里面的
AbortTransaction += new System.EventHandler(AbortTransactionEvent);
CommitTransaction += new System.EventHandler(CommitTransactionEvent);

-----------------------------------------------------------------------------

虽然.NET 2.0对事务提供了很好的支持，但是没有必要总是使用事务。使用事务的第一条规则是，在能够使用事务的时候都应该使用事务，但是不要使用过度。原因在于，每次使用事务，都会占用一定的开销。另外，事务可能会锁定一些表的行。还有一条规则是，只有当操作需要的时候才使用事务。例如，如果只是从数据库中查询一些记录，或者执行单个查询，在大部分时候都不需要使用显式事务。

    开发人员应该在头脑中始终保持一个概念，就是用于修改多个不同表数据的冗长事务会严重妨碍系统中的所有其他用户。这很可能导致一些性能问题。当实现一个事务时，遵循下面的实践经验能够达到可接受的结果：（1）避免使用在事务中的SELECT返回数据，除非语句依赖于返回数据；（2）如果使用SELECT语句，只选择需要的行，这样不会锁定过多的资源，而尽可能的提高性能；（3）尽量将事务全部写在T-SQL或者API中；（4）避免事务与多重独立的批处理工作结合，应该将这些批处理放置在单独的事务中；（5）尽可能避免大量更新。
另外，必须注意的一点就是事务的默认行为。在默认情况下，如果没有显式的提交事务，则事务会回滚。虽然默认行为允许事务的回滚，但是显式回滚方法总是一个良好的编程习惯。这不仅仅只是释放锁定数据，也将使得代码更容易读并且更少错误。

-----------------------------------------------------------------------------
NOLOCK　可能把没有提交事务的数据也显示出来．
READPAST 会把被锁住的行不显示出来　
不使用　NOLOCK 和 READPAST　，在 Select 操作时候则有可能报错误：事务(进程 ID **)与另一个进程被死锁在 锁 资源上，并且已被选作死锁牺牲品。

select count(*) from t1 WITH(NOLOCK)
select count(*) from t1 WITH(READPAST)

HOLDLOCK 持有共享锁，直到整个事务完成，应该在被锁对象不需要时立即释放，等于SERIALIZABLE事务隔离级别 其他事务能读不能改
NOLOCK 语句执行时不发出共享锁，允许脏读 ，等于 READ UNCOMMITTED事务隔离级别
PAGLOCK 在使用一个表锁的地方用多个页锁
READPAST 让sql server跳过任何锁定行，执行事务，适用于READ UNCOMMITTED事务隔离级别只跳过RID锁，不跳过页，区域和表锁
ROWLOCK 强制使用行锁
TABLOCKX 强制使用独占表级锁，这个锁在事务期间阻止任何其他事务使用这个表，其他事务不能读写
UPLOCK 强制在读表时使用更新而不用共享锁

锁有两种分类方法。
（1） 从数据库系统的角度来看
锁分为以下三种类型：

独占锁（Exclusive Lock）
独占锁锁定的资源只允许进行锁定操作的程序使用，其它任何对它的操作均不会被接受。执行数据更新命令，即INSERT、 UPDATE 或DELETE 命令时，SQL Server 会自动使用独占锁。但当对象上有其它锁存在时，无法对其加独占锁。独占锁一直到事务结束才能被释放。
共享锁（Shared Lock）
共享锁锁定的资源可以被其它用户读取，但其它用户不能修改它。在SELECT 命令执行时，SQL Server 通常会对对象进行共享锁锁定。通常加共享锁的数据页被读取完毕后，共享锁就会立即被释放。
更新锁（Update Lock）
更新锁是为了防止死锁而设立的。当SQL Server 准备更新数据时，它首先对数据对象作更新锁锁定，这样数据将不能被修改，但可以读取。等到SQL Server 确定要进行更新数据操作时，它会自动将更新锁换为独占锁。但当对象上有其它锁存在时，无法对其作更新锁锁定。

（2）从程序员的角度看
锁分为以下两种类型：

乐观锁（Optimistic Lock）
乐观锁假定在处理数据时，不需要在应用程序的代码中做任何事情就可以直接在记录上加锁、即完全依靠数据库来管理锁的工作。一般情况下，当执行事务处理时SQL Server会自动对事务处理范围内更新到的表做锁定。
悲观锁（Pessimistic Lock）
悲观锁对数据库系统的自动管理不感冒，需要程序员直接管理数据或对象上的加锁处理，并负责获取、共享和放弃正在使用的数据上的任何锁。

转载于:https://www.cnblogs.com/haungshenbo/articles/2417763.html