Web 服务、ADO.NET 连接池、超时错误
如果我有一个仅公开一次调用的 .asmx Web 服务。 它采用一些参数并将这些值作为 SQL Server 2005 表中的记录插入。 该方法应该是什么样子才能对 ADO.NET 连接池尽可能“友好”？ 如果它每秒可能被多个客户端调用 10 次（分散），那么它应该是什么样子。 我还应该调整其他设置吗？
目前我收到错误：
System.Web.Services.Protocols.SoapException：
服务器无法处理请求 --> System.Data.SqlClient.SqlException：超时已过期。 操作前超时时间已过或服务器未响应。
如果连接池有问题，错误会有所不同吗？ 我如何判断这是否是连接池问题、SOAP 限制，或者我的数据库是否太繁忙而导致调用确实超时？
If I have an .asmx Web Service that only exposes one call. One that takes a few params and inserts those values as a record in SQL Server 2005 table. What should that method look like to be as "kind" to the ADO.NET Connection Pool as possible? What should it look like if its going to be called maybe 10 times a second (spread out) over multiple clients. Any other settings I should tweak?
Currently I'm getting the error:
System.Web.Services.Protocols.SoapException:
Server was unable to process request --> System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to the operation or the server is not responding.
Would the error be different if the connection pool was the problem?
How can I tell if this is a connection pool issue, a SOAP limitation, or if my database is so busy that the calls are really timing out?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您没有发布有关您正在做的事情的一些最重要的信息。 事实上，它是一个网络方法，这是一个转移注意力的事实，它只是归结为数据库问题以及你对它的锤炼程度。
正如例外情况所示，您可能在这里遇到连接问题（我不认为它与池有任何关系）。 您在尝试打开连接或尝试执行操作时是否收到此消息？ 每个都有一个单独的超时，因此显式打开连接然后调用该操作可能是一个好主意，这样您就可以看到超时发生的位置。
另外，我想看看您是否正在使用交易。 如果这包含在连接中，并且操作超时，并且您正在使用事务，那么您是否使用事务来访问包含在事务中的其他任何位置（读取或写入）的此表？ 到时候可能会陷入僵局。
除此之外，如果不是这种情况，那么就是连接问题，您必须检查机器和服务器是否正确配置数据库（例如，您是否使用 tcp ip、命名管道或共享内存）运营。
You are not posting some of the most important information about what you are doing. The fact that it is a webmethod is a red-herring, it simply comes down to a database issue and how much you are hammering it.
It would seem that you might have a connectivity issue here, as the exception states (and I don't believe it has anything to do with the pool). Are you getting this when trying to open the connection, or when trying to execute the operation? Each one has a separate timeout, so it might be a good idea to explicitly open the connection and then make the call to the operation, so you can see where the timeout is occuring.
Also, I would look to see if you are using transactions. If this is encompassed in a connection, and the timeout is on the operation, and you are using transactions, then are you using transactions to access this table anywhere else (read or write) that is wrapped in a transaction? It might be a deadlock at that point.
Barring all that, if that is not the case, then it's a connectivity issue and you have to look to see if the machine and server are configured correctly (are you using tcp ip, named pipes, or shared memory, for example) for database operations.