我正在尝试使用不正确的IsolationLevels来处理我们的应用程序中是否存在数据库连接问题.我们的应用程序是使用SQL Server 2005的.Net 3.5数据库应用程序.
我发现连接的IsolationLevel在返回到连接池时没有被重置(参见这里),并且在这篇博文中读到每个新创建的TransactionScope都有自己的连接池分配给它时也很惊讶.
我们的数据库更新(通过我们的业务对象)在TransactionScope中进行(为每个业务对象图更新创建一个新的).但我们的提取不使用显式事务.所以我想知道的是,我们是否可能遇到这样的情况:我们的获取操作(应使用默认的IsolationLevel - Read Committed)将重用已用于更新的池中的连接,并继承更新IsolationLevel (REPEATABLEREAD)？或者我们的更新是否会保证使用不同的连接池,因为它们包含在TransactionScope中？
提前致谢,
格雷厄姆
sql-server connection-pooling transactionscope isolation-level .net-3.5
我们在应用程序中通过SqlCommand SELECT在SQL Server数据库上执行查询来获取一些数据列表.我们没有在SqlCommand上显式设置事务,而只是将它传递给SqlConnection并运行它.是否是这样的情况,当没有指定SQL Server将启动并使用默认的IsolationLevel的默认事务ReadCommitted？
我们的客户遇到了数据库应用程序的一些阻塞问题.我们要求他们运行阻塞进程报告跟踪,他们给我们的跟踪显示在SELECT和UPDATE操作之间发生阻塞.跟踪文件显示以下内容:
所以基本上我们不知道为什么SELECT查询的隔离级别不是默认的ReadCommitted IsolationLevel,更令人困惑的是,为什么查询的IsolationLevel会随着时间的推移而改变？只有一个客户看到此行为,因此我们怀疑它可能是数据库配置问题.
有任何想法吗？
提前致谢,
格雷厄姆
当通过SQL从SQL服务器查询返回大型数据集时,我们的数据层存在一些问题DataReader.当我们使用DataReader填充业务对象并将它们序列化回客户端时,提取可能需要几分钟(我们向用户显示进度:-)),但我们发现有一些相当硬核锁定正在进行在受影响的表上导致其他更新被阻止.
所以我想我的稍微天真的问题是,由于执行查询而被取出的锁实际上放弃了什么？我们似乎发现锁一直存在,直到最后一行DataReader被处理并且DataReader实际上已经关闭 - 这看起来是否正确？快速了解DataReader幕后工作将如何很好,因为我一直在努力寻找任何体面的信息.
我应该说,我意识到锁定问题是主要问题,但我只关心DataReader这里的行为.