By way of introduction, I have an application utilizing three AJAX
CascadingDropDown lists whose contents are served up by one of three
WebMethods. The first two of these three dropdowns are for Entity Type and
Entity Groups. The Entity Group gets populated based on the Entity Type
selected from the first dropdown. The problem is the Entity Group also needs
to be limited by the Area ID for the area in which the user is working. From
all the documentation on CascadingDropDown lists I've seen, they can pass on
only one parameter to a WebMethod. The only solution I can think of is to
have a separate WebMethod which would take the Area ID and store it as an
integer property in the WebService which could then be retrieved when the
WebMethod for populating the Entity Group dropdown requires it.

The asmx file for the WebService is located in the same directory in which
the aspx page requiring it is located and the code-behind for the service is
in the App_Code directory off the application's root directory; in other
words, it isn't exactly a standalone WebService.

My questions are as follows:
When the WebService is first used, does it continue to run in memory
on the
server after a user has finished calling the required WebMethods waiting
on
another request from that user?
If several people require use of the WebService, is a separate
WebService
instantiated for each of the users or is there only a single instance of
it?

If there is only a single instance of the WebService, I'll have to rethink
using the CascadingDropDowns. This is due to a scenario in which User A, who
is in Area 1, is utilizing the service and then User B, who is in Area 2,
also requires it; in this case, the Entity Group for each user would then be
based on whoever the last person was to set the Area ID property according to
their area.

"AlBruAn" <albruan (AT) hotmail (DOT) com.(donotspam)> wrote

No. After each request, the instance of your [WebService] class is
discarded.

A separate instance of the [WebService] class is instantiated for each
request. It has nothing to do with the "people", just with the requests.

You should rethink your idea of storing state in the web service, for
several reasons. The first is that state costs scalability, so you should
get into the habit of writing stateless services.

Also, it doesn't sound like you need to store state. If you need to pass
area id plus the entity type, then pass them as a string, separated by comma
or "|" or something. Let the web service split the string into its two
pieces.
--
John Saunders [MVP]