Windows 2003 中可用于 JDBC 连接的套接字数量
我的团队使用纯 JDBC（无连接池）和 JTDS 驱动程序，用 Java 构建了一个 Windows 服务，该服务连接到 Windows 2003 Server 中的 SQL Server 2005。
一段时间后，打开数据库连接的方法开始引发异常，并显示以下堆栈跟踪：
java.net.BindException: Address already in use: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl .java:305)
at java.net.PlainSocketImpl.connectToAddress(PlainSoc ketImpl.java:171)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.j ava:158)
at java.net.Socket.connect(Socket.java:452)
at java.net.Socket.connect(Socket.java:402)
at java.net.Socket.<init>(Socket.java:309)
at java.net.Socket.<init>(Socket.java:124)
尽管程序员在完成后很小心地关闭连接，但有些事情并不顺利。
目前，我们解决了切换到命名管道协议的问题（因为所有内容都托管在同一台机器上），但这只是一个临时解决方案。
我用谷歌搜索了这个问题，看来我们应该使用一些连接池库，例如 c3p0。 这是解决问题的唯一方法吗？
我可以尝试提高 Windows 2003 中的套接字限制吗？
My team built a Windows Service in Java that connects to a SQL Server 2005 in a Windows 2003 Server, using pure JDBC (no connection pooling) with the JTDS driver.
After a while, the method that opens the connections to the database start raising exceptions with the following stack trace:
java.net.BindException: Address already in use: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl .java:305)
at java.net.PlainSocketImpl.connectToAddress(PlainSoc ketImpl.java:171)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.j ava:158)
at java.net.Socket.connect(Socket.java:452)
at java.net.Socket.connect(Socket.java:402)
at java.net.Socket.<init>(Socket.java:309)
at java.net.Socket.<init>(Socket.java:124)
Although the programmers were careful to close connections when they were done, something is not going right.
For the time being, we solved the problem switching to the Named Pipes protocol (since all is hosted in the same machine), but this is a temporary solution.
I've googled for the problem and it seems we should be using some connection pooling library such c3p0. Is this the only solution to the problem?
Could I try to raise the sockets limit in Windows 2003?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您是否以非常快的速度打开/关闭连接？ 当 TCP 连接关闭时，它们会在 TIME_WAIT 状态下停留一段时间。 在 Windows 上，它们存在的默认时间是 240 秒。 听起来您可能有相当多的 tcp 连接处于 TIME_WAIT 状态。
您可以通过运行 netstat 来检查这一点。 如果您有大量与数据库服务器处于 TIME_WAIT 状态的 tcp 连接，连接池将解决您的问题。
您可以尝试提高套接字限制，和/或缩短连接处于 TIME_WAIT 状态的时间。 但这会改变所有 tcp 连接的行为。 因此，使用连接池:) 我们使用 dbcp 作为 Java 中的连接池解决方案。
Are you opening / closing connections at a very rapid rate? When a TCP connection is closed, they hang around for a little while in the TIME_WAIT state. On Windows, the default time they exist is 240 seconds. It sounds like you might have quite a few tcp connections in the TIME_WAIT state.
You can check this by running netstat. If you have a huge number of tcp connections to the database server in the TIME_WAIT state, a connection pool will fix your issue.
You can try to raise the socket limit, and/or lower the time a connection will stay in the TIME_WAIT state. But this will alter the behavior of all tcp connections. So use a connection pool :) We use dbcp as our connection pool solution in Java.
看来您的连接确实没有关闭。 或者您试图错误地重新使用连接...
出于各种性能原因，强烈建议使用连接池。 例如，您不需要每次都创建连接，这非常昂贵。 重新使用连接会带来巨大的变化。
其次，你真的想创建自己的池化机制吗？ 它并不像看起来那么简单，有很多特殊的线程问题。 使用经受时间考验的现有库要容易得多。
It really looks like you're connections aren't being closed. That or you're trying to re-use the connection incorrectly...
It's strongly recommend to use a connection pool for various performance reasons. For example, you won't need to create a connection each time, which is very expensive. Re-using connections makes a world of difference.
Secondly, do you really want to create your own pooling mechanism? It's not as simple as it appears, there are lots of idiosyncratic threading issues. It's much easier to just use an existing library that's withstood the test of time.