以后还是事务了--之二

这一篇将解决上一篇中的一些不好的地方,其实在写这篇之前,是要感谢各位的,因为就是有

了你们我才能够找到自己的不足,也认识到自己的眇小,我记得在与老师做过项目之后,说过这

样的一句话,我说,在没有做过项目之前,我感觉自己的能力还是蛮强的,但做过之后,就感觉自

已越来越菜.

======================================================

先说一下,上篇中的一些性能的对比是有着问题的,就是对事务认识不够清楚,忘记了

"RMDBS所谓的ACID原则，核心就是事务管理机制。"
还有就是不了解

"这个很正常呀，如果没有显示的事务控制，那么数据库会默认
每一个INSERT是一个事务 ，所以 你没有加事务控制时 效率低 "

后来我做了一个试验,我做的测试确实是有一点问题,

代码如下:

Code connectString = @"data source=M204-128"SQL2005;initial catalog=RecruitDB;user id=sa;password=sa";
            using (SqlConnection conn = new SqlConnection(connectString))
            {
                conn.Open();

                SqlCommand command = new SqlCommand();
                command.Connection = conn;
                command.CommandType = CommandType.Text;

                SqlTransaction tran = null;
                for (int i = 0; i < 100000; i++)
                {
                    try
                    {

                        tran = conn.BeginTransaction();
                        command.Transaction = tran;

                        command.CommandText = "INSERT INTO InsertTest VALUES(" + i.ToString() + ",'abc','abc','www','123')";
                        command.ExecuteNonQuery();

                        tran.Commit();
                    }
                    catch (Exception ex)
                    {
                        try
                        {
                            tran.Rollback();
                        }
                        catch
                        {
                            throw new Exception("");
                        }
                    }
                }
            }

也就是按照 毁于随  说的那样确实是有问题

在没有使用显示事务的情况下,用时121406ms,使用显示事务用时163046ms,这个也就说明了我以前的那个测试是

不正确的,在msdn中有两篇文章,我翻译如下(有删节)

<Explicit Transactions>

显示事务就是你明确的定义了事务开始和结束的事务.

在ado.net中,SqlConnection 对象的BeginTransaction 方法开始一个显示的

事务,在调用SqlTransaction 对象的Commit  或者 Rollback 方法之后,这个显示事务就会结束..

显示事务模式只会存在于一个事务之内,当显示事务完成之后,事务的模式会还原成为在这个事务开始之

前的自动提交或者隐式模式.

<Coding Efficient Transactions>

要尽可能保证事务的简短性是非常重要的.

当一个事务开始的时候,DBMS出于事务的ACID特性会独占一些资源一直到事务的结束.比如在更改数据时,

事务会一直阻止其它事务对正在更改数据的访问直到此事务的结束.还有一点,

有些事务的锁粒度,甚至连select这样的语句也会独占数据直到事务的结束.

由于事务的这样的特性,所以尤其在多用户系统中要尽可能的保证事务的简短,以减少在并发连接中的数据独占.

长时间低效的事务在少用户的系统中可能不会是个问题,但在有上千用户的系统中,由于事务锁带来的独占性所

带来的阻塞问题就不能让人忍受了.

以下是一些建议:

不要在使用事务时要求用户输入

尽可能的不要在浏览数据时使用事务

要尽可能 的保证事务的简短性

可能考虑用行级别的只读查询锁来减少独占

要想尽办法尽可能的使用低级别的事务锁等级

 

还有一篇文章,有兴趣可能去看看

深入sql server中的事务

还有enhydraboy这里的也都要看看,

所以说我在前一篇中的性能比较是有问题的,因为它们的比较好象不是在一个平线上的,比较也就没有了什么意义.

如果说给谁带来了错误的认识在此就sorry了.

================================================================

One day I'll Be a Hero