In a VB.Net Windows Service I'm currently pooling units of work with:
ThreadPool.QueueUserWorkItem(operation, nextQueueID)
In each unit of work (or thread I'll use for ease of understanding), it will make a couple MSSQL operations like so:
Using sqlcmd As New SqlCommand("", New SqlConnection(ConnString))
With sqlcmd
.CommandType = CommandType.Text
.CommandText = "UPDATE [some table]"
.Parameters.Add("@ID", SqlDbType.Int).Value = msgID
.Connection.Open()
.ExecuteNonQuery()
.Connection.Close() 'Found connections not closed quick enough'
End With
End Using
When running a netstat -a -o
on the server I'm seeing about 50 connections to SQL server sitting on IDLE
or ESTABLISHED
, this seems excessive to me especially since we have much larger Web Applications that get by with 5-10 connections.
The connection string is global to the application (doesn't change), and has Pooling=true
defined as well.
Now will each of these threads have their own ConnectionPool
, or is there one ConnectionPool
for the entire .EXE process?