事务是将一系列操作作为一个单元执行,要么成功,要么失败,回滚到最初状态。
在事务处理术语中,事务要么提交,要么中止。若要提交事务,所有参与者都必须保证对数据的任何更改是永久的。不论系统崩溃或是发生其他无法预料的事件,更改都必须是持久的。只要有一个参与者无法做出此保证,整个事务就会失败。事务范围内的所有数据更改将回滚到特定设置点。如图所示:
在一个系统中存在事务是必须的,通过各种查找资料,大概了解到在.net中大概分为4种事务。在这里先简单介绍一下,具体实现在以后呈现。
1.数据库事务
在数据库中使用的自身的事务,一般写在存储过程中。
优点:执行效率最佳
缺点:第一,事务仅在数据库中调用,难以实现复杂的逻辑。
第二,复用率很差,更换一个数据库就不能进行调用。
代码结构:
Create procedure pro_exampletran
//开始事务
Begin Tran
//提交事务
Commit tran
//回滚事务
Rollback tran
2.
代码中的事务
在代码中直接写的事务。
优点:简单,和数据库中的实现差不多。但是移植数据库不受影响。
缺点:不能实现分布式,也就是跨数据库调用。
代码结构:
//使用new新生成一个事务
SqlTransaction myTrans=myConnection.BeginTransaction();
Try
{
/*事务性代码块*/
//事务提交
myTrans.Commit();
}
Catch(Exception e)
{
//事务回滚
myTrans.Rollback();
}
Finally
{
myConnection Close();
}
3.TransactionScope事务
TransactionScope类事务用户限定事务代码块,自动可以提升为分布式事务。上面两种类型的事务只能操作同一个数据库,不能跨数据库操作,这时就可以用TransactionScope事务。可以操作不同的数据库。
代码结构:
public void exampletransactionScope()
{
using (TransactionScope trans = new TransactionScope())
{
/*在这里实现事务性工作*/
//提交事务。
trans.Complete();
}
}
4.com+事务
在COM+中,提供了完整的事务服务,我们可以利用它来完成分布式应用程序的事务控制。
代码结构:
public void examplecomtransaction()
{
//指定事务类型
sc.Transaction = TransactionOption.Required;
//设置启动跟踪
sc.TrackingEnabled = true;
//创建一个上下文,该上下文的配置由作为 cfg 参数传递的 ServiceConfig 对象来指定。
//随后,客户端和服务器端的策略均被触发,如同发生了一个方法调用。
//接着,新的上下文被推至上下文堆栈,成为当前上下文
ServiceDomain.Enter(sc);
try
{
//提交事务
ContextUtil.SetComplete();
}
catch
{
//回滚事务
ContextUtil.SetAbort();
throw;
}
finally
{
conn.Close();
//触发服务器端的策略,随后触发客户端的策略,如同一个方法调用正在返回。
//然后,当前上下文被弹出上下文堆栈,调用 Enter 时正在运行的上下文成为当前的上下文。
ServiceDomain.Leave();
}
}
事务还在慢慢研究中,尤其是最后两个事务几乎没有怎么用过,接下来就在实践中慢慢探索。