I have created a ASMX Web Service which does some Active Directory stuff behind the scene.
As I wish to retain certain information within Web Services under user session, I have decided to put [WebMethod(EnableSession = true)] and start using Session variables.
However, when I turn that option on, the return time from app -> web service -> app has became ridiculously long. (about a minute or more).
If I remove [WebMethod(EnableSession = true)], it is fairly fast.
Anyone know what is going on?
Possible reasons:
Session state is stored out of process (state server/ SQL server) and getting/storing it taking a long time
You are making multiple concurrent requests (including service requests) under the same session. ASP.NET ensures that only one session-full (session read/write) request execute at a time and hence, multiple concurrent requests would queue up.
EDIT :
For #2, obvious solution is to avoid session state use - for example, can you put the relevant information into another store such as cache or database (expensive).
If you are only reading session state in web service then you may take advantage of read-only session state (see IReadOnlySessionState). Read-only session state allows concurrent read-only requests - read/write request will still block all other requests. Now, EnableSession from WebMethod attribute does not support this - it either provides no session or read/write session. So one of the workaround can be to implement your own handler implementing IReadOnlySessionState and then route asmx request to thi handler using a http-module and then switch the handler to default one later. Because your handler requires read-only session state, you will have the read-only session state - see this forum post where such http-module that switches the handler has been given.
Related
In ASP.NET when you have 2 AJAX requests on the same web page calling 2 controller actions, if they use the session then one will lock out the other
You can get readonly access to the session which can help, but not if you want to write to the session
You can override the session class, e.g.
https://www.red-gate.com/simple-talk/dotnet/asp-net/single-asp-net-client-makes-concurrent-requests-writeable-session-variables/, but this doesn't really help for the same reason
In my case the controller action calls a long running external server call. While this is happening ideally the session would be released and saved back to memory, and then when the call is finished the session would be read back in, possibly being blocked if another call is still proceeding
NB Whether or not the external server call is called in an async manner makes no difference unfortunately
Is there any way of doing this? Possibly by overriding some internal classes?
In out project we need to execute a few AJAX calls in a row asynchronously, so the next call doesn't have to wait for previous to return. And even though client issues calls asynchronously, server processes them sequentially due to Session lock.
Since we don't need to modify Session in these calls, we marked page that AJAX calls with EnableSessionState="ReadOnly"via #Page directive. And it worked, calls became truly async and no longer depend on each other timing. But what we found out - in that backend code Session is writable despite being marked as ReadOnly. We can assign values to Session and the values persist. Is this a bug or behavior by design?
I'd say this behavior is a "by design" gotcha of in-process session state (which, unfortunately, doesn't seem to be well documented).
Out-of-Process Session State (State Server or SQL Server)
At the beginning of every request, ASP.NET loads and deserializes session data from external storage into memory. Each request gets its own copy of the data, so changes to the data won't affect other concurrent requests in the same session.
if EnableSessionState is set to ReadOnly, then at the end of the request, the data are simply discarded rather than serialized back to external storage.
In-Process Session State
No serialization or deserialization occurs. Instead, there's a single set of session data in memory which lives for the duration of the session. Each request in the same session shares that set of data, and changes to the data are immediately visible to other concurrent requests.
I suppose the ASP.NET team could have made Session read only when EnableSessionState is set to ReadOnly:
this.Session["Customer"] = customer; // Why not throw InvalidOperationException?
But ASP.NET would still have no way of detecting changes to the objects themselves:
Customer customer = (Customer)this.Session["Customer"];
customer.Address = address; // ASP.NET can't detect this.
Therefore, it's your responsibility as a developer to avoid changing session data if you set EnableSessionState to ReadOnly. Otherwise, you may introduce multithreading bugs.
I have a ASP.Net API implementation, where to store and access the data / variables across consecutive calls, I am using a session state object as shown below and it can be successfully accessed in the multiple calls to separate calls by a browser:
// Access the current session object
var blSession = HttpContext.Current.Session;
// create the BL object using the user id
BL accessBL = new BL(userID);
// Store the Bl object in the session object dictionary
blSession["UserBL"] = accessBL;
I have to enable the following setting in the Global.asax, for the Session object to be accessible:
protected void Application_PostAuthorizeRequest()
{
// Enable session state in the web api post authorization
HttpContext.Current.SetSessionStateBehavior(SessionStateBehavior.Required);
}
Issue comes in when the WebAPI shown above has to be accessed via another ASP.Net MVC client, which is separately hosted on a different machine, at that time same consecutive calls do not maintain the state as shown above and thus it leads to an exception, since the consecutive calls rely on session data to proceed.
I have seen a similar issue when I seen the similar issue when I use the Fiddler Debugger, as it gets hosted as a web proxy, so consecutive calls through that too fails, since it does not maintain the state. In my understanding, issue is due to setting the Cookie across domain, which doesn't seem to work across domains due to security reason
I know a workaround is to use an application wide variable like Cache, but please suggest if you have a way to get the SessionState work. Let me know if you need more details.
If you have not setup an alternative way to do SessionState, then the default behavior is to do it InMemory on the server. This is why you are seeing issues when the request is handled by a different ASP.NET server.
Web API calls are meant to be stateless. That is, they should not perform like a classic ASP.NET application that relies on the framework to store user specific information in Session variables across HTTP requests. For each call, pass in a user-specific identifier or token that you can then use to lookup information stored in your backend. You can store this information in your database or a distributed cache like MemCache for faster retrieval.
I've an application which has some controller's actions calling slow 3rd party web services. These actions are called using AJAX calls from the page.
I can use async controllers to free ASP.NET thread pool, that's great. But what about session? If I use InProc session and a request made to "slow action" the particular user can't make any request to the application because his session is locked by first "slow" call.
In PHP there is a method session_write_close() which I can use as following:
Accept user's request to slow action
Check rights of the user to access controller/action based on session data
Write something to the session if needed
Call session_write_close(). From this point session is closed by this request and any other request from the same user can access it
Make my slow call (maybe in some async way)
I know that I can disable session state on the controller level using [SessionState] attribute, but that's not the solution.
Any ideas?
I think it could be several scenarios.
1) make changes in controller factory and change it to produce contorllers without session or with some custome session implementation
2) try to read this article about sessionless controllers
How does IIS handles multiple simultaneous requests to a web service using the same session id when that web service relies on sessions?
If the first web service call has not finished processing, does IIS queue the second web service call temporarily until the first web service call has finished (since they both rely on the same session data).
Or does IIS allow both requests to go forward and any changes made to the session store by the first request immediately affect the second web service call in process even thought that may cause unexpected results.
I believe it is using the first option by queuing the second call until the first is completed due to session reader\writer locks but I have not been able to locate a definitive answer.
Note: In this case the web service requests are generated from the client browser asynchronously.
Yes, like anything else that's using session state, the session state module is going to block the request from going any further down the pipeline (i.e. executing your ASMX web method) until it can aquire the lock to the session. Session state is the enemy of concurrency, avoid it at all costs.