之前遇到过这么一种情况：
连接数据库的部分Session会出现不定时的阻塞，这种阻塞时长时短，有时候持续较长时间，有时间持续时间较短，没有什么规律。
之后分析相关存储过程和代码写法，发现是阻塞源头的存储过程中开启了事务，而应用程序在调用存储过程发生异常之后没有进行特别的处理（提交或者回滚），
那么在执行方法发生异常之后，连接关闭了，但是数据库中遗留有活动事务（dbcc opentran对应的SessionId是sleeping状态），于是就产生了阻塞。
关键是活动事务会不定时自己消失，就有点诡异了，这是本文的重点。
这种机制跟连接池有关：
当应用程序连接数据库的时候开启了连接池，如果应用程序调用了一个开启了事务操作的存储过程，
当发生异常的时候，有可能会出现数据库连接关闭，而存储过程中的事务既没有提交，也没有回滚的情况。
这种情况下就会产生“孤立事务”，也就是说，因为打开事务的数据量连接断掉了，而事务还处于活动状态，
实际上开启连接池的情况下，数据库连接的关闭，并不是物理上的关闭，而是将数据库连接返回到连接池。
此时如果没有外界的干预，包括没有对这个数据库连接没有被重用，或者这个连接没有物理断开，或者是没有重启应用程序，或者没有数据库服务器，这个事务将一直持续下去。
因为活动事务将阻塞其他Session对相关表的排他性访问，所以就表现为阻塞。
如何判断是否发生了连接池中的连接重用
首先，一个连接数据库的过程中，有没有重用连接池中的连接，在SQL Server中有哪些区别？
以ado.net为例，如果在连接字符串中加入pooling=false;则表示不启用连接池.
如下，连续执行两次数据库访问，两次数据库访问均在连接字符串中加入了pooling=false;表示不启用连接池
