On my website, members can write articles to share info with others in their community. I get random reports that the submit fails, and it appears it is because of session timeout.
If I create a small ajax script to "ping" an action on my ASP.NET MVC controller every few minutes, would that reset the session timeout? Or is there a better way?
An ajax ping is what I do in my Java EE MVC web application to keep the session alive, and it works fine. I don't see why it should not work for a ASP.NET application as well.
I am not sure if there is a better way, though.
Yes, that will do the job.
Independently of the technologies, every time an http request reaches the http server, the session "last access time" is updated to the date the communication has been initiated by the client.
If you ping to the server with a delay less than the session timeout you will preserve the session for ever!
Note: you don't need to ping every minutes if your session time out is 30 minutes. It will overload the network for absolutely nothing. I would recommend the session to ping every 25 minutes for such configuration.
HIH
M.
Related
I am currently debugging some issue about this.
We have a ASP.NET web application and I am debugging on Cassini. When I tried to use IE and send out the request to the server, some time (e.g. in about 20minutes) is needed to process and then send out the response.
In case of multi-tab IE, I tried to send out the requests in different tab at about the same time to the same server but the response is handled only after the one of the response is sent out.
If a new instance of IE is started and the requests are sent out in these different instances, the server can process and send out the response almost simultaneously. After doing some research I found that IIS express may solve my problem, but I cannot. Anyone has experienced similar problem or have I missed out some really important things to check with first?
Thank you for your help.
This is primarily due to ASP.net's session state variable and the fact that only one request at a time may have R/W access to a particular session (as determined by the SessionID cookie).
Any additional requests requiring any form of session access (since Read/Write is the default) will be blocked until the previous request has been completed.
Based on the following links:
http://johnculviner.com/asp-net-concurrent-ajax-requests-and-session-state-blocking/
https://msdn.microsoft.com/en-us/library/ms178581.aspx?f=255&MSPPError=-2147217396
I think that you miss the point that the session is lock all request leaving only one per time to run.
Read about that and why:
Replacing ASP.Net's session entirely
Also : Web app blocked while processing another web app on sharing same session
The reason is that Sessions in ASP.NET are not thread safe. Therefore ASP.NET serializes access to requests from the same session.
If you have a multi-tab IE then your tabs share one session. The first request is executed right off and the other ones are queued. If you have different instances then each of them creates a new session and therefore the request are executed in parallel.
I have a hosted Silverlight 4 application. My task is to notify a Silverlight user when his ASP.NET session is about to expire with a simple dialog box, saying something like "Your session is about to expire, would you like to reset the session?" with two buttons [Yes], and [No]. When the user clicks [Yes] I would like to update the ASP.NET session, otherwise I would just let it expire. What is the best methodology to use here?
I've taken a look at different forums, and most people just simply poll the server every-so-often from the page hosting the Silverlight application. This wouldn't do for me. I thought of creating a singleton DispatcherTimer that would start on Silverlight application startup, would fetch Session.Timeout value from the server using WCF and would run for (Session.Timeout - some delta) minutes. When the timer expires it would pop the notification window. Moreover, since this notification window should only pop after a period of inactivity, I'd like to reset this timer every time a WCF call is performed (which essentially defines activity). Is this sound? Are there any better methods? What are your thoughts?
P.S. I'm also planning on doing something similar for Forms timeout.
You may or may not be opposed to this, but I've found it useful in RIAs to have a timer running that makes a keep-alive request to the ASP.NET server in order to prevent the session from expiring while the application is active. At the same time, in case something happened on the server that caused the session to expire, you could detect that condition in the keepalive handling and tell the client that the expiration has taken place.
Let's imaging there are 2 pages on the web site: quick and slow. Requests to slow page are executed for a 1 minute, request to quick 5 seconds.
Whole my development career I thought that if 1st started request is slow: he will do a (synchronous) call to DB... wait answer... If during this time request to quick page will be done, this request will be processed while system is waiting for response from DB.
But today I've found:
http://msdn.microsoft.com/en-us/library/system.web.httpapplication.aspx
One instance of the HttpApplication class is used to process many requests in its lifetime. However, it can process only one request at a time. Thus, member variables can be used to store per-request data.
Does it mean that my original thoughts are wrong?
Could you please clarify what they mean? I am pretty sure that thing are as I expect...
The requests have to be be processed in the sequential order on the server side if the both request use the same session state with read/write access, because of asp.net session locking.
You can find more information here:
http://msdn.microsoft.com/en-us/library/ie/ms178581.aspx
Concurrent Requests and Session State
Access to ASP.NET session state is exclusive per session, which means that if two different users make concurrent requests, access to each separate session is granted concurrently. However, if two concurrent requests are made for the same session (by using the same SessionID value), the first request gets exclusive access to the session information. The second request executes only after the first request is finished. (The second session can also get access if the exclusive lock on the information is freed because the first request exceeds the lock time-out.) If the EnableSessionState value in the # Page directive is set to ReadOnly, a request for the read-only session information does not result in an exclusive lock on the session data. However, read-only requests for session data might still have to wait for a lock set by a read-write request for session data to clear.
Your original thoughts are right, and so is the documentation. The IIS worker process can spawn many threads, each with their own instance of the HttpApplication class.
ASP .NET will host multiple AppDomains for your web application under a single worker process (w3wp.exe). It may even share AppDomains for different web applications under the same worker process (if they are assigned to the same app pool).
Each AppDomain that ASP .NET creates can host multiple HttpApplication instances which serve requests and walk through the ASP .NET lifecycle. Each HttpApplication can (as you've said) respond to one request at a time.
Does anyone know a standard way to keep alive the http session as long user has open the flex app in the browser?
I played around with the polling mechanism of blazeds. But it had no affect on the http session.
Why do you need the http session to stay alive?
We have authentication enabled in our flex-weborb-.net application. If the session is terminated, the next call to weborb will throw a security exception. In this case we just re-authenticate and do the server call again. A new session is created and the user can continue his work. Like this, no polling is needed. I guess it's the same with blazeds.
If the session must stay the same, then I would suggest to ping the server every couple of minutes depending on the session timeout value.
There is no standard way of doing this. We do a ping-pong with the server every n-seconds (check the AS3 Timer class), where n must be lower than the session timeout. It's best to keep your session timeout as low as possible to reduce memory consumption on the server, especially when you have a lot of concurrent users.
One option is to submit an AJAX keepalive request from javascript in the hosting HTML page.
I have an iframe keep alive (iframe that hits a page, defibrillator.aspx, on my site every few minutes to keep the session alive) on my masterpage for an asp.net app. This works most of the time but every so often my session variables return null during the page load on my defibrillator page. At first, I thought the session was being timed out by the server for some reason so I put some logging into the Session_End event in the global.asax but it was never hit.
Any ideas what could cause the session to be lost.
Many things can cause session to be lost. An AppPool recycle, iisreset, the client could lose its session cookie, etc. Without knowing more it is difficult to tell what is the problem.
If session is so critical that you poll the application to keep the worker process from sleeping perhaps you ought to look into persisting your session state to SQL Server.
Peter Bromberg outlines the primary reasons for ASP.NET session timeouts on his blog.
I had this same sort of problem, storing a shopping cart state in Session but having it randomly return null instead. I think I found the answer on Bertrand Le Roy's blog, which seems to work for me:
Session loss problems can also result
from a misconfigured application pool.
For example, if the application pool
your site is running is configured as
a web farm or a web garden (by setting
the maximum number of worker processes
to more than one), and if you're not
using the session service or SQL
sessions, incoming requests will
unpredictably go to one of the worker
processes, and if it's not the one the
session was created on, it's lost. The
solutions to this problem is either
not to use a web garden if you don't
need the performance boost, or use one
of the out of process session
providers.
Blog
If the chosen persistence mechanism is InProc then it can be triggered by many things. Totally counter-recommended for a production environment.