另一个走向极端的错误
??满怀信心的新手们可能为自己所掌握的部分知识陶醉不已，刚接触数据库库事务处理的准开发者们也一样，踌躇满志地准备将事务机制应用到他的数据处理程序的每一个模块每一条语句中去。的确，事务机制看起来是如此的诱人——简洁、美妙而又实用，我当然想用它来避免一切可能出现的错误——我甚至想用事务把我的数据操作从头到尾包裹起来。
??看着吧，下面我要从创建一个数据库开始：
| using System; using System.Data; using System.Data.SqlClient; namespace Aspcn { public class DbTran { file://执行事务处理 public void DoTran() { file://建立连接并打开 SqlConnection myConn=GetConn(); myConn.Open(); SqlCommand myComm=new SqlCommand(); SqlTransaction myTran; myTran=myConn.BeginTransaction(); file://下面绑定连接和事务对象 myComm.Connection=myConn; myComm.Transaction=myTran; file://试图创建数据库TestDB myComm.CommandText="CREATE database TestDB"; myComm.ExecuteNonQuery(); file://提交事务 myTran.Commit(); } file://获取数据连接 private SqlConnection GetConn() { string strSql="Data Source=localhost;Integrated Security=SSPI;user id=sa;password="; SqlConnection myConn=new SqlConnection(strSql); return myConn; } } public class Test { public static void Main() { DbTran tranTest=new DbTran(); tranTest.DoTran(); Console.WriteLine("事务处理已经成功完成。"); Console.ReadLine(); } } } ??//--------------- |
未处理的异常： System.Data.SqlClient.SqlException: 在多语句事务内不允许使用 CREATE DATABASE 语句。
| at System.Data.SqlClient.SqlCommand.ExecuteNonQuery() at Aspcn.DbTran.DoTran() at Aspcn.Test.Main() |
??注意，如下的SQL语句不允许出现在事务中：
| ALTER DATABASE | 修改数据库 |
| BACKUP LOG | 备份日志 |
| CREATE DATABASE | 创建数据库 |
| DISK INIT | 创建数据库或事务日志设备 |
| DROP DATABASE | 删除数据库 |
| DUMP TRANSACTION | 转储事务日志 |
| LOAD DATABASE | 装载数据库备份复本 |
| LOAD TRANSACTION | 装载事务日志备份复本 |
| RECONFIGURE | 更新使用 sp_configure 系统存储过程更改的配置选项的当前配置（sp_configure 结果集中的 config_value 列）值。 |
| RESTORE DATABASE | 还原使用BACKUP命令所作的数据库备份 |
| RESTORE LOG | 还原使用BACKUP命令所作的日志备份 |
| UPDATE STATISTICS | 在指定的表或索引视图中，对一个或多个统计组（集合）有关键值分发的信息进行更新 |
??除了这些语句以外，你可以在你的数据库事务中使用任何合法的SQL语句。
另一个走向极端的错误
??满怀信心的新手们可能为自己所掌握的部分知识陶醉不已，刚接触数据库库事务处理的准开发者们也一样，踌躇满志地准备将事务机制应用到他的数据处理程序的每一个模块每一条语句中去。的确，事务机制看起来是如此的诱人——简洁、美妙而又实用，我当然想用它来避免一切可能出现的错误——我甚至想用事务把我的数据操作从头到尾包裹起来。
??看着吧，下面我要从创建一个数据库开始：
| using System; using System.Data; using System.Data.SqlClient; namespace Aspcn { public class DbTran { file://执行事务处理 public void DoTran() { file://建立连接并打开 SqlConnection myConn=GetConn(); myConn.Open(); SqlCommand myComm=new SqlCommand(); SqlTransaction myTran; myTran=myConn.BeginTransaction(); file://下面绑定连接和事务对象 myComm.Connection=myConn; myComm.Transaction=myTran; file://试图创建数据库TestDB myComm.CommandText="CREATE database TestDB"; myComm.ExecuteNonQuery(); file://提交事务 myTran.Commit(); } file://获取数据连接 private SqlConnection GetConn() { string strSql="Data Source=localhost;Integrated Security=SSPI;user id=sa;password="; SqlConnection myConn=new SqlConnection(strSql); return myConn; } } public class Test { public static void Main() { DbTran tranTest=new DbTran(); tranTest.DoTran(); Console.WriteLine("事务处理已经成功完成。"); Console.ReadLine(); } } } ??//--------------- |
未处理的异常： System.Data.SqlClient.SqlException: 在多语句事务内不允许使用 CREATE DATABASE 语句。
| at System.Data.SqlClient.SqlCommand.ExecuteNonQuery() at Aspcn.DbTran.DoTran() at Aspcn.Test.Main() |
??注意，如下的SQL语句不允许出现在事务中：
| ALTER DATABASE | 修改数据库 |
| BACKUP LOG | 备份日志 |
| CREATE DATABASE | 创建数据库 |
| DISK INIT | 创建数据库或事务日志设备 |
| DROP DATABASE | 删除数据库 |
| DUMP TRANSACTION | 转储事务日志 |
| LOAD DATABASE | 装载数据库备份复本 |
| LOAD TRANSACTION | 装载事务日志备份复本 |
| RECONFIGURE | 更新使用 sp_configure 系统存储过程更改的配置选项的当前配置（sp_configure 结果集中的 config_value 列）值。 |
| RESTORE DATABASE | 还原使用BACKUP命令所作的数据库备份 |
| RESTORE LOG | 还原使用BACKUP命令所作的日志备份 |
| UPDATE STATISTICS | 在指定的表或索引视图中，对一个或多个统计组（集合）有关键值分发的信息进行更新 |
??除了这些语句以外，你可以在你的数据库事务中使用任何合法的SQL语句。
隔离级别的概念
??企业级的数据库每一秒钟都可能应付成千上万的并发访问，因而带来了并发控制的问题。由数据库理论可知，由于并发访问，在不可预料的时刻可能引发如下几个可以预料的问题：
脏读：包含未提交数据的读取。例如，事务1 更改了某行。事务2 在事务1 提交更改之前读取已更改的行。如果事务1 回滚更改，则事务2 便读取了逻辑上从未存在过的行。
不可重复读取：当某个事务不止一次读取同一行，并且一个单独的事务在两次（或多次）读取之间修改该行时，因为在同一个事务内的多次读取之间修改了该行，所以每次读取都生成不同值，从而引发不一致问题。
幻象：通过一个任务，在以前由另一个尚未提交其事务的任务读取的行的范围中插入新行或删除现有行。带有未提交事务的任务由于该范围中行数的更改而无法重复其原始读取。
??如你所想，这些情况发生的根本原因都是因为在并发访问的时候，没有一个机制避免交叉存取所造成的。而隔离级别的设置，正是为了避免这些情况的发生。事务准备接受不一致数据的级别称为隔离级别。隔离级别是一个事务必须与其它事务进行隔离的程度。较低的隔离级别可以增加并发，但代价是降低数据的正确性。相反，较高的隔离级别可以确保数据的正确性，但可能对并发产生负面影响。
??根据隔离级别的不同，DBMS为并行访问提供不同的互斥保证。在SQL Server数据库中，提供四种隔离级别：未提交读、提交读、可重复读、可串行读。这四种隔离级别可以不同程度地保证并发的数据完整性：
| 隔离级别 | 脏 读 | 不可重复读取 | 幻 像 |
| 未提交读 | 是 | 是 | 是 |
| 提交读 | 否 | 是 | 是 |
| 可重复读 | 否 | 否 | 是 |
| 可串行读 | 否 | 否 | 否 |
??可以看出，“可串行读”提供了最高级别的隔离，这时并发事务的执行结果将与串行执行的完全一致。如前所述，最高级别的隔离也就意味着最低程度的并发，因此，在此隔离级别下，数据库的服务效率事实上是比较低的。尽管可串行性对于事务确保数据库中的数据在所有时间内的正确性相当重要，然而许多事务并不总是要求完全的隔离。例如，多个作者工作于同一本书的不同章节。新章节可以在任意时候提交到项目中。但是，对于已经编辑过的章节，没有编辑人员的批准，作者不能对此章节进行任何更改。这样，尽管有未编辑的新章节，但编辑人员仍可以确保在任意时间该书籍项目的正确性。编辑人员可以查看以前编辑的章节以及最近提交的章节。这样，其它的几种隔离级别也有其存在的意义。
??在.net框架中，事务的隔离级别是由枚举System.Data.IsolationLevel所定义的：??
| [Flags] [Serializable] public enum IsolationLevel |
??其成员及相应的含义如下：
| 成 员 | 含 义 |
| Chaos | 无法改写隔离级别更高的事务中的挂起的更改。 |
| ReadCommitted | 在正在读取数据时保持共享锁，以避免脏读，但是在事务结束之前可以更改数据，从而导致不可重复的读取或幻像数据。 |
| ReadUncommitted | 可以进行脏读，意思是说，不发布共享锁，也不接受独占锁。 |
| RepeatableRead | 在查询中使用的所有数据上放置锁，以防止其他用户更新这些数据。防止不可重复的读取，但是仍可以有幻像行。 |
| Serializable | 在DataSet上放置范围锁，以防止在事务完成之前由其他用户更新行或向数据集中插入行。 |
| Unspecified | 正在使用与指定隔离级别不同的隔离级别，但是无法确定该级别。 |
??显而意见，数据库的四个隔离级别在这里都有映射。
??默认的情况下，SQL Server使用ReadCommitted(提交读)隔离级别。
??关于隔离级别的最后一点就是如果你在事务执行的过程中改变了隔离级别，那么后面的命名都在最新的隔离级别下执行——隔离级别的改变是立即生效的。有了这一点，你可以在你的事务中更灵活地使用隔离级别从而达到更高的效率和并发安全性。
最后的忠告
??无疑，引入事务处理是应对可能出现的数据错误的好方法，但是也应该看到事务处理需要付出的巨大代价——用于存储点、回滚和并发控制所需要的CPU时间和存储空间。
??本文的内容只是针对Microsoft SQL Server数据库的，对应于.net框架中的System.Data.SqlClient命名空间，对于使用OleDb的情形，具体的实现稍有不同，但这不是本文的内容，有兴趣的读者可以到.net中华网（）的论坛里找到答案。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/631872/viewspace-863313/ ，如需转载，请注明出处，否则将追究法律责任。
