这 MSDN文章指出：

  

这是隔离级别具有连接范围   范围，一旦为连接设置   用SET事务隔离   LEVEL语句，它仍然有效   直到连接被关闭或   另一个隔离级别设置。当一个   连接关闭，并返回到   池，从隔离级别   最后的事务隔离级别设置   声明被保留。随后   连接重用汇集   连接使用的隔离级别   那是在生效的时间   连接池。

的SqlConnection类没有任何成员可能持有的隔离级别。那么，如何连接知道什么隔离级别中运行？？？

我问这个的原因是因为以下情形的：

在我使用开了一个交易 在TransactionScope的序列化 模式，说T1。 在打开的T1连接。 在T1结束/处置，连接 追溯到连接池。 在叫上同其他查询 连接（从获得后 连接池），这个查询运行 在串行化模式！

问题：

如何进行连接池仍 知道什么是隔离级别是 与之关联??? 如何将其恢复为其他 交易层面???   

解析：   为什么池连接正在返回的序列化隔离级别的原因是因为以下原因：

        您有一个连接池（比方说CP1）   在CP1可能有50个连接。   您从CP1挑一个连接C1和序列化执行。这种连接有隔离级别现在设置。   不管你做什么，这不会被重置（除非该连接   用于执行一个code在一个不同的隔离层）。   执行查询C1（序列化）后，可以追溯到CP1。   如果步骤1-4再次执行，那么使用可能会比C1其他一些连接的连接，让我们说C2或C3。所以，这也将   有它的隔离级别设置为序列的。   所以，慢慢的，Serialzable被设置为在CP1多个连接。   当您执行操作中，没有明确的隔离级别设置正在做一个查询，连接从CP1挑将决定   隔离级别。对于如如果这样的查询请求为连接   和CP1用C1（序列化）来执行这个查询，然后这个查询   会即使您没有显式串行化模式下执行   设置。         

希望扫清了一些疑虑。 ：）

解决方案

隔离级别在底层数据库管理系统实现的，说SqlServer的。设置隔离级别最有可能设置里面设置的隔离级别的连接SQL命令。

在DBMS保持隔离级别，只要连接保持打开状态。由于连接被放入池中，它保持打开状态，并保持之前的设定。

在与隔离级别瞎搞，您应该重新设定隔离级别在任何交易的结束，或者，甚至更好，将其设置在请求一个新的连接。

This MSDN article states that:

An isolation level has connection-wide scope, and once set for a connection with the SET TRANSACTION ISOLATION LEVEL statement, it remains in effect until the connection is closed or another isolation level is set. When a connection is closed and returned to the pool, the isolation level from the last SET TRANSACTION ISOLATION LEVEL statement is retained. Subsequent connections reusing a pooled connection use the isolation level that was in effect at the time the connection is pooled.

The SqlConnection class has no member that may hold the isolation level. So how does a connection know what isolation level to run in???

The reason I'm asking this is because of the following scenario:

I opened a transaction using TransactionScope in Serializable mode, say "T1". Opened a connection for T1. T1 is finished/disposed, connection goes back to connection pool. Called another query on same connection (after getting it from connection pool) and this query runs in serializable mode!!!

Problem:

How does the pooled connection still know what isolation level was associated to it??? How to revert it back to some other transaction level???

Resolution: The reason why pooled connections are returning the serializable isolation level is because of the following reason:

You have one connection pool (let's say CP1) CP1 may have 50 connections. You pick one connection C1 from CP1 and execute it with Serializable. This connection has its isolation level set now. Whatever you do, this will not be reset (unless this connection is used to execute a code in a different isolation level). After executing the query C1(Serializable) goes back to CP1. If steps 1-4 are executed again then the connection used may be some other connection than C1, let's say C2 or C3. So, that will also have its isolation level set to Serializable. So, slowly, Serialzable is set to multiple connections in CP1. When you execute a query where no explicit isolation level setting is being done, the connection picked from CP1 will decide the isolation level. For e.g. if such a query requests for a connection and CP1 uses C1(Serializable) to execute this query then this query will execute in Serializable mode even though you didn't explicitly set it.

Hope that clears a few doubts. :)

解决方案

Isolation levels are implemented in the underlying DBMS, say SqlServer. Setting the isolation level most probably sets up SQL commands which set the isolation level for the connection.

The DBMS keeps the isolation level as long as the connection stays open. Because the connections is put into the pool, it stays open and keeps the settings made before.

When messing around with isolation levels, you should either reset the isolation level at the end of any transaction, or, even better, set it when a new connection is requested.