ADO.NET 连接池如何与 .ASMX Web 服务配合使用？
我创建了一个旧式 .ASMX Web 服务，并想知道内置的 ADO.NET 连接池如何与其配合使用。
Web 服务不使用单例模式，因此它会根据每个请求重新实例化。我的问题是，在每次服务请求后，连接是否会从池中删除，或者跨请求保留在池中？我的服务被频繁调用，但我不想每次都进行连接的设置和拆除（如果可以避免的话）。
我读到该池是为 AppDomain 维护的，但我不确定每个请求是否都会生成一个新的 AppDomain。
我也很好奇在这种情况下设置 Min Pool Size（设置为 0 以外的小数字）是否有益。
有人知道吗？
I've created an old-style .ASMX web service and would like to know how the built-in ADO.NET connection pooling works with it.
The web service is not using a singleton pattern, so it is instantiated anew with every request. My question is will connections be removed from the pool after each service request, or are they kept in the pool across requests? My service is called very frequently but I don't want to be doing setup and teardown of connections every time, if it can be avoided.
I have read that the pool is maintained for the AppDomain, but I'm not sure if each request generates a new AppDomain or not.
I am also curious if it would be beneficial to set Min Pool Size (to a small number other than 0) in this case.
Anyone know?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
否，每个请求不会生成新的应用程序域。该网站/应用程序的所有请求都位于同一应用程序域中，因此共享连接池。一旦 asmx 请求完成连接，它会将其返回到池中，并且队列中的下一个请求会获取它（假设池中没有其他可用的连接）。
澄清一点。您可以有两个不同的 Web 应用程序，它们指向相同的代码，并且位于不同的应用程序域中。这两个应用程序不共享任何内容（想象一下启动同一个应用程序两次）。
因此，根据应用的不同，它可能是有益的。建立联系需要时间，因此做好一些准备可以让您放弃这一点。如果您有一个使用一个连接的请求，那么让一个人等待可能会很好（这完全取决于您希望应用程序响应的速度）。当您需要为一个请求开放 3 或 4 个不同的（您明白了）时，这一点确实可以发挥作用。那么为什么需要多个连接呢？一个用于访问数据的线程和一个用于记录到数据库的单独线程怎么样（记录到数据库与记录到文件是完全不同的对话）？现在你需要两个。有多种场景可以发挥作用。根据您的数据库服务器保持开放连接的成本可能相当便宜，因此将其设置为较小的数字可能会带来巨大的收益。 （根据记录，我见过连接数据库需要几秒钟的情况，例如 3-5 秒，因此在这种情况下，为用户保留打开的连接是有益的。）
这是针对最大池大小的
不，这没有好处，因为对该服务的所有请求都使用相同的池（假设连接使用相同的连接字符串，并且没有访问不同的服务器。这些服务器具有单独的连接池）。没有可用的连接是一种非常快速且肯定会破坏服务性能的方法。
No each request does not generate a new app domain. All the requests for that web site/application are in the same application domain, and so share the connection pool. Once the asmx request is finished with the connection, it returns it to the pool and the next request in line grabs it (assuming there isn't another connection in the pool readily available).
One point of clarification. You can have two different web applications which point to the same code, and are in different app domains. The two applications don't share anything (think about launching the same application twice).
So it can be beneficial depending on the application. Creating connections takes time, so having some ready allows you to forgo that. If you have request that say uses one connection, that might be fine to make a person wait for (it all depends on fast you want the application to respond). This can really come into play when you need to say 3 or 4 different ones (you get the point) open for one request. So why would you need multiple connections? What about one for accessing data and a separate thread for logging to the database (logging to the database vs a file is a totally different conversation)? Now you need two. There are multiple scenarios where this can come into play. Depending on your database server holding an open connection can be pretty cheap, so setting it to a small number can be a huge bang for your buck. (For the record I've seen scenarios where connecting to a database took several seconds, like 3-5, so in that case holding an open connection for a user was beneficial.)
This is for Max Pool Size
No it's not beneficial, because all requests to that service use the same pool (assuming the connections are using the same connection string, and aren't hitting different servers. Those have separate connection pools). Having no available connections, is a really fast and surefire way of crushing the performance of your service.