问题描述
1）我注意到您关闭SqlConnection的实例后，你仍然能够重新打开相同的连接：
1) I noticed that after you close SqlConnection instance, you are still able to re-open the same connection:
A）你能告诉我是怎么回事幕后？这意味着，当我们关闭文件流对象，我们无法重新打开它，而是必须创建一个新的对象 - 所以为什么不与SqlConnection的对象一样吗？
a) can you tell me what is going on behind the scenes? Meaning, after we close file stream object, we can’t re-open it, but instead must create a new object – so why isn’t the same with SqlConnection objects?
b）若启用了连接池，那么我假设连接对象返回到连接池以后可以重复使用？
b) If pooling is enabled, then I assume the connection object is returned back to the connection pool and can later be reused?!
但后来我们怎么知道，经过重新开放连接，我们会得到相同的SqlConnection实例作为前我们最初关闭它？我问，是因为据我所知，即使连接池有几个可用的连接，这些对象的SqlConnection可以在不同的状态比原来的SqlConnection对象（由不同的状态：我的意思是某些属性可以持有比那些不同的价值观在原始的连接对象）？！
But then how do we know that after re-opening the connection we will get the same Sqlconnection instance as before we initially closed it? I’m asking this because as far as I know, even if connection pool has several connections available, these SqlConnection objects could be in different state than original SqlConnection object ( by "different state" I mean that some properties could hold different values than those in "original" connection object)?!
c）如果池未启用什么？是否重新净SqlConnection对象从零开始？
同样，在我们最初关闭SqlConnection对象，我们可能已经改变了一些属性的值？编译器如何知道如何重新创建国家SqlConnection对象是我们之前关闭它？
c) What if pooling isn’t enabled? Does .Net recreate SqlConnection object "from scratch"? Again, before we initially closed the SqlConnection object, we might have changed values of some properties? How will compiler know how to recreate the state SqlConnection object was in before we closed it?
感谢您
推荐答案
SqlConnection的是没有直接摆在首位的真正的连接。之后连接池的样子。我不知道是肯定的，但我也不会惊讶地发现，如果你重新打开的SqlConnection，你可以在不同的物理网络连接结束。
SqlConnection isn't directly the "real" connection in the first place. The connection pool looks after that. I don't know for sure, but I wouldn't be surprised to find that if you reopen the SqlConnection you could end up on a different "physical" network connection.
您可以的写的一个的FileStream 这使得重开 - 如果它一直跟踪文件的名称，以及底层的手柄，它可能只是试图重新打开它，与所有可能的故障等，只是不是非常有用的。 （我不能说，我觉得能够重新打开的SqlConnection 有用的个人，诚然。）
You could write a FileStream which allowed reopening - if it kept track of the name of the file as well as the underlying handle, it could just try to reopen it, with all the possible failures etc. It's just not very useful. (I can't say that I find being able to reopen SqlConnection useful personally, admittedly.)
在知道你会得到相同的的SqlConnection 目标方面 - 你是不是要求它返回到的SqlConnection 对象，你只是一个调用的现有的对象的方法。该引用不会改变 - 对象仅仅是国家（或别的东西它是指可能的状态）
In terms of knowing that you'll get "the same SqlConnection object" - you aren't calling a method which returns a reference to a SqlConnection object, you're just calling a method on an existing object. That reference won't change - just the state of the object (or possibly the state of something else it refers to).
我不知道如果不启用池会发生什么。它不能创建一个全新的的SqlConnection 对象（或者更确切地说，它可以，但不会的替换的你已经有了一个参考一）。我怀疑这一切归结为的SqlConnection 被周围的包装别的东西 - 与别的东西当然可以重新
I don't know what would happen if pooling weren't enabled. It couldn't create a brand new SqlConnection object (or rather it could, but that wouldn't replace the one you already had a reference to). I suspect it all boils down to SqlConnection being a wrapper around "something else" - and the "something else" could certainly be recreated.
这篇关于重新开放的SqlConnection实例的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！