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.

 

[JohnH]

Everything in a Module is Shared. Most likely the web service application behaves same as ASP.Net web application for a shared variables, treating them as application state.

 

[Kane Jeeves]

Related issue?

This seems related to this issue I posted yesterday: http://www.vbdotnetforums.com/web-services/28762-web-service-sql-connections.html
Is it?

 

[petersgyoung]

When 2 clients attempt to access the same resources at the same time, concurrency issue arises. Legacy web service does not have easy way to handle concurrency (correct me if I am wrong). If you are using .Net 3.5, why not consider using WCF service. In WCF service you can set the InstanceControlMode to Single (the service will work like a singleton) and control the concurrency setting for a service by ConcurrencyMode property of ServiceBehaviorAttribute. When the service is configured for Single concurrency mode, a lock is acquired for the service object while a request is being processed by that object. Other calls to the same object are queued in the order of receipt at the service. Under this arrangement, you problem will be solved automatically.

 

[Kane Jeeves]

Seems like a major issue?

Let's see if I have this right. Let's say I write a web service that has a variable that stores a persons name, account #, and checking account balance. (No one would ever do this hopefully, but you get my example). The service is called by John Smith from my website, the variable is set with info, and a millisecond later it's called again by Sally Jones. Do you mean to say that since the web service and it's resources, like the variable, is shared there's a chance John Smith would have Sally Jones' info returned to him? Seems like a major issue. I almost can't believe individual calls to a particular web service aren't compartmentalized in their own space somehow.

 

[petersgyoung]

Hi Kane

There is no concurrency issue in your case. Web Service will start a new thread for each call. What I am talking about is singleton mode (i.e. a mode that allow WCF Service to start one thread to serve all clients - please note that the default mode of WCF Service is PerCall which is the same as Web Service).

 

[Kane Jeeves]

Still Confused

So if a new thread is started for each call, how is the original poster having his issues? I was thinking my issues were similar: in his case he was talking about datasets. In mine I was talking about connections, sqldatareader, etc, but the basic issue seems to be the same. Two individual calls into a web service appear to use data (in datasets or connections) from the other.

(Using IIS7, .NET 2.0)

 

[JohnH]

So if a new thread is started for each call, how is the original poster having his issues?

Because all threads use same shared application memory.

 

[Kane Jeeves]

Petersgyoung said my example isn't a problem, but JohnH just said it was.

From JohnH's description of shared app memory it sounds like my post from 8:32 (Let's see if...) is in fact a major issue. How do folks get around this?

 

[petersgyoung]

Hi Kane

If you deliberately put your variable in shared app memory, JohnH is correct. However, by default Web Service calls are state-unaware. So, concurrency is not an issue in your case. Instancing and concurrency are complicated issues. Unless you know exactly what you are doing, I do not recommend you to put variable in shared app memory. If you need to, there are a number of ways to implement custom synchronization, including Monitor, Mutex, ReadWriterLock, Interlocked operations, etc. For additional information on multithreading techniques, I suggest you read books on this topic. It is difficult to explain in Forum.

 

[JohnH]

True, poeple are more aware of this when coding ASP.Net applications, global variables is useless for storing state between requests and Shared variables is never used, instead explicit Application and Session server state variables and other state management tools is used in that environment. Using shared variables is generally not good OOP technique.

 

[Kane Jeeves]

Thanks, I will read up. One more question: what do you mean by "put your variable in shared app memory"? I'm guessing that's something more than just declaring a variable as usual.

TIA

 

[petersgyoung]

Hi Kane

Because Web Services are ASP.Net applictions, you can use ASP.Net Application and Session state to maintain state in your XML Web Services. For more information about sharing global variable in your Web Services, perhaps you can search Google or MSDN with the key word HttpApplicationState class.

 

[Kane Jeeves]

So in my web service I'm not using app or session state to store info. But is asp.net itself using app or session state for things like datareaders, sql connections and so on? In my original post I wanted to know if connections and datareaders are somehow shared (even though I'm not specifically storing them in app/session state). I have your typical WS that opens a reader, grabs data, closes reader and connection. Nothing fancy. But when this WS is called for example 5 times in one second the connections and readers seem to get tripped up. I get HasRow errors, reader already open errors, etc. I thought my WS would be completely segregated from other instances where it's running.

 

[petersgyoung]

Hi Kane

You issue is more likely on database than on Web Service. I do not know your code and the type of your back end database. I guest you are reading a large set of data from MSDE. If this is the case, change MSDE to SQL Express 2005. MSDE limits connection to 5 concurrent users!