Question Web service shares the same public variables during simultaneous requests

[nismo]

I have a web service, and it contains a module containing public datasets. These datasets are populated when a request comes into the <WebMethod> function, and the execution then follows a lengthy process in order to build up a class which is ultimately returned by the web service. Along the way, this path constantly refers back to these public datasets in order to obtain information (hence why they are public members in a module - they need to be accessible from all classes/functions in the web service code).

The problem is, when a second request comes in and sets the datasets while the first one is still running, the process that was already running starts using the new information. The result is that the user who issues the first request gets an obscured and corrupted response because it completed half the process with one set of data, and the other half with a different set of data (due to the second request coming in and changing the datasets).

The datasets are delcared like this;

Public Module DataStore
Public DSFares As DataSet
End Module

There are NO static or shared members anywhere in the entire code.
The client application is the same for everyone and point to the same web service location. The problem can be consistently reproduced with 2 clients pressing the button at the same time in 2 completely different geographical locations, using completely different networks and machines.

I made the assumption that each web service request is served in its own space, its own context where variables dont conflict with each other during simultaneous requests. Obviously im wrong... and i just need some advice as to where i go from here.

Both the client app and the web service is written using VB.NET 2008 SP1 running on framework 3.5 SP1
The server which hosts the web service is Windows Server 2008 using IIS 7.0.

 

[Kane Jeeves]

Nope, using SQL Server 2000 with full connection pooling, etc. on a pretty robust machine. Not querying large amounts of data either. The thing that seems to be tripping up the connections and readers is the # of times the service is called.

Basic code is below. There are some nested sql call similar to this in code that downstream in the routine this appears in.

Dim sSQL As String = String.Empty
Dim dr As SqlDataReader = Nothing
Dim dt As New DataTable

sSQL = "SELECT * FROM XYZ WHERE ID = 123"

Dim cmd As New SqlCommand(sSQL, oConn)

Try
	oConn.Open()
	dr = cmd.ExecuteReader

	If dr.HasRows Then
		dt.Load(dr)
	Else
		'return error
	End If

Catch ex As Exception
	'return error

Finally
	If Not dr Is Nothing Then
		dr.Close()
	End If
	cmd.Dispose()
	oConn.Close()
End Try

 

[petersgyoung]

Hi Kane

Perhaps you can use SqlDataAdapter instead of SqlDataReader.

Dim da As New SqlDataAdapter(strSQL, objConnect)
Dim dt As New DataTable
da.Fill(dt)