为了压系统,昨天小组在测试环境模拟了一大批订单数据。今天上午查看记录的账单计息日志,发现了一大堆的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!
时间: 2024-10-28 22:09:12