Intermittent error establishing socket on SQL Server 2000

Question

I have a suite of 130 JUnit tests. Recently, they started to give me intermittent "error establishing socket" errors when trying to connect to a local instance of SQL Server 2000 via JDBC.
Each test creates one or more connections. I've used wrappers to prove that I'm closing all of the connections, statements, prepared statements and result sets. The first 70 or 80 tests succeed. After that every test gets the "error establishing socket" exception. Sometimes (but not always) SQL Server continues to refuse connections when I re-run the suite. When that happens I have to let it sit for 30 seconds or so (or restart the server) before it will accept connections.
I've tested this with both Microsoft's and WebLogic's JDBC drivers with the same results. There's nothing in the SQL Server logs when this happens. There's nothing in the Windows event logs, either.
If I sleep for 5 seconds between each test the problem goes away.
I installed the latest service pack (SP3a) for SQL Server 2000 with no change in behavior.
All of this leads me to believe that something is wrong with SQL Server. Has anyone else run into this problem? Any ideas?

Answer 1

I am not overly familiar with the SQL Server network architecture, but there are scenarios that could explain your intermittent failures.
When you connect to a database one of two things can happen, you can start your own process on the server that acts as communication to from the server locally, or you are put in a queue for a static (shared) process that does the same thing.
Assuming that most databases are initially setup with singular processes per connection, and you have established a connection then you disconnect from the database you do not automatically or instantly kill your process running on the server. There are two primary reasons for this as far as I know. First, the database puts more priority on doing something then doing nothing. Cleaning up and removing your process would be considered doing nothing, accepting incoming connections would be considered doing something. Second, the process may have to stay around to ensure all commit or rollback is completed properly (not always true in every database).
So, I would expect that there is a connection limit (perhaps between 50-80) that you are exceeding because you are firing these connections rapidly and even though you close the connection in your remote program, the database simply doesn't keep up. Most databases will "cleanup" reasonably quickly if they have the resources to do so, so if you were to put a 30 second delay between every connection it would probably work just fine. It would probably work fine if you put a 30 second delay between after every 20 connections too. It's a bit of balancing act.
There would be a couple of ways to alleviate this constraint. Putting in delays can demonstrate that this is in fact a work load problem (constrained by total count of connections), but doesn't really help in production instances. You can change the maximum number of connections allowed by the database, however this threshold may be caused by hardware resource (memory) limitations as much as it is a parameter in the database. You may have to add memory to accommodate this many connections. You may have to constrain how much memory each connection gets (again controlled by database parameters). You may have to accept this as a resource constraint and write your code accordingly. This often manifests itself by taking advantage of transaction managers (or transaction manager logic) that will queue up requests until database resources are available.
Again, I'm not a SQL Server expert, but I'm reasonably certain that most of what I said applies if not specifically at least generally.
Good Luck.