为了压系统，昨天小组在测试环境模拟了一大批订单数据。今天上午查看记录的账单计息日志，发现了一大堆的MySqlException
MySql.Data.MySqlClient.MySqlException (0x80004005):
There is already an open DataReader associated with this Connection which must be closed first.
诸如：
2017-01-05 00:40:49.891
账单计息异常/{"BillId":1000012082,"OrderId":"DD201701040002672"}:MySql.Data.MySqlClient.MySqlException (0x80004005): There is already an open DataReader associated with this Connection which must be closed first.
在 MySql.Data.MySqlClient.ExceptionInterceptor.Throw(Exception exception)
在 MySql.Data.MySqlClient.MySqlCommand.Throw(Exception ex)
在 MySql.Data.MySqlClient.MySqlCommand.ExecuteReader(CommandBehavior behavior)
在 MySql.Data.MySqlClient.MySqlCommand.ExecuteDbDataReader(CommandBehavior behavior)
在 System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader(CommandBehavior behavior)
在 CommonLibrary.CommonOrm.CommonOrm_Dapper.<QueryImpl>d__11`1.MoveNext() 位置 e:\work\yijia\trunk\CommonLibrary\CommonOrm\CommonOrm_Dapper.cs:行号 1554
在 System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
在 System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
在 CommonLibrary.CommonOrm.CommonOrm_Dapper.Query[T](IDbConnection cnn, String sql, Object param, IDbTransaction transaction, Boolean buffered, Nullable`1 commandTimeout, Nullable`1 commandType) 位置 e:\work\yijia\trunk\CommonLibrary\CommonOrm\CommonOrm_Dapper.cs:行号 1444
在 GateWay.DAL.BillsDal.BillsDal.GetOrdersBillList(String bizOrderId) 位置 e:\work\yijia\trunk\GetWay.DAL\BillsDal\BillsDal.cs:行号 123
在 GateWay.BLL.Bills.BillsBll.GetOrdersBill(String bizOrderId, BillTypeEnum billType) 位置 e:\work\yijia\trunk\GetWay.BLL\Bills\BillsBll.cs:行号 27
在 GateWay.BLL.Bills.PrincipalBillsInterest.InterestBill(t_bills principleBill) 位置 e:\work\yijia\trunk\GetWay.BLL\Bills\PrincipalBillsInterest.cs:行号 186
在 GateWay.BLL.Bills.PrincipalBillsInterest.Interest() 位置 e:\work\yijia\trunk\GetWay.BLL\Bills\PrincipalBillsInterest.cs:行号 77
通过分析程序，发现dal层的所有方法都是静态的，其中还包括一个静态的db连接对象：
public class BillsDal
{
static IDbConnection _conn = ConnUtility.GateWayConntion;
/// <summary>
/// 获取指定业务订单的所有账单（by 商户code和订单号）
/// </summary>
/// <param name="bizOrderId">订单Id，唯一</param>
/// <returns></returns>
public static List<t_bills> GetOrdersBillList(string merCode, string bizOrderNo)
{
var obj = _conn.Query<t_bills>("select * from t_bills where merCode='" + merCode + "' and orderNo='" + bizOrderNo + "'");
return obj.ToList();
}
}
突然想到之前整理的blog《static，你还敢用吗？》，所以，不难分析出来原因：问题就出在这个静态的db连接对象_conn上，因为所有类的实例始终是用一个db连接，当并发出现时，又没有lock数据操作代码，那么，就很容易出现连接在未关闭时又要被建立并打开，这样就出现了db连接异常。
经模拟多线程来测试，的确如此。
问题即答案！修复这个bug的话，有如下2个方案：
- 如果仍然要保留这个static的_conn字段，就要用lock来锁住数据操作代码（GetOrdersBillList），以控制并发冲突
- 每次查询时用一个新的连接对象。
方案分析：第1种，涉及到对象只能在被释放（关闭）掉才能再次被使用（打开），性能低下，不可取。 第2种呢，其实在dal层，绝大多数的程序猿都是按照每一个数据操作只用一个db连接的方式来编码的。 由于大家一般不会把dal类的成员定义成static，所以，也就不会遇到这样的db连接异常。而我呢，倾向于用static方法，考虑到封装，就把这个db连接对象封装成静态字段了，反而忽视了静态数据成员带来的隐患——数据量小时几乎是暴露不出来问题，一旦数据量大起来，有了并发，就会出现资源被同时使用，这样的话，多个线程实例都要修改其状态时，就出现了并发异常。
由此来看，依然用static的话，就要把_conn当做只读的私有属性（不考虑代码味道）：
static IDbConnection _conn
{
get { return ConnUtility.GateWayConntion; }
}
这样，当每次访问这个属性时，都会返回一个新的连接对象。
再次模拟多线程测试，ok！
