Asked  7 Months ago    Answers:  5   Viewed   82 times

I just discovered that every request in an ASP.Net web application gets a Session lock at the beginning of a request, and then releases it at the end of the request!

In case the implications of this are lost on you, as it was for me at first, this basically means the following:

  • Anytime an ASP.Net webpage is taking a long time to load (maybe due to a slow database call or whatever), and the user decides they want to navigate to a different page because they are tired of waiting, THEY CAN'T! The ASP.Net session lock forces the new page request to wait until the original request has finished its painfully slow load. Arrrgh.

  • Anytime an UpdatePanel is loading slowly, and the user decides to navigate to a different page before the UpdatePanel has finished updating... THEY CAN'T! The session lock forces the new page request to wait until the original request has finished its painfully slow load. Double Arrrgh!

So what are the options? So far I have come up with:

  • Implement a Custom SessionStateDataStore, which ASP.Net supports. I haven't found too many out there to copy, and it seems kind of high risk and easy to mess up.
  • Keep track of all requests in progress, and if a request comes in from the same user, cancel the original request. Seems kind of extreme, but it would work (I think).
  • Don't use Session! When I need some kind of state for the user, I could just use Cache instead, and key items on the authenticated username, or some such thing. Again seems kind of extreme.

I really can't believe that the ASP.Net Microsoft team would have left such a huge performance bottleneck in the framework at version 4.0! Am I missing something obvious? How hard would it be to use a ThreadSafe collection for the Session?



OK, so big Props to Joel Muller for all his input. My ultimate solution was to use the Custom SessionStateModule detailed at the end of this MSDN article:

This was:

  • Very quick to implement (actually seemed easier than going the provider route)
  • Used a lot of the standard ASP.Net session handling out of the box (via the SessionStateUtility class)

This has made a HUGE difference to the feeling of "snapiness" to our application. I still can't believe the custom implementation of ASP.Net Session locks the session for the whole request. This adds such a huge amount of sluggishness to websites. Judging from the amount of online research I had to do (and conversations with several really experienced ASP.Net developers), a lot of people have experienced this issue, but very few people have ever got to the bottom of the cause. Maybe I will write a letter to Scott Gu...

I hope this helps a few people out there!

Tuesday, June 1, 2021
answered 7 Months ago

This is the reason

When using cookie-based session state, ASP.NET does not allocate storage for session data until the Session object is used. As a result, a new session ID is generated for each page request until the session object is accessed. If your application requires a static session ID for the entire session, you can either implement the Session_Start method in the application's Global.asax file and store data in the Session object to fix the session ID, or you can use code in another part of your application to explicitly store data in the Session object.

So basically, unless you access your session object on the backend, a new sessionId will be generated with each request


This code must be added on the file Global.asax. It adds an entry to the Session object so you fix the session until it expires.

protected void Session_Start(Object sender, EventArgs e) 
    Session["init"] = 0;
Saturday, June 5, 2021
answered 6 Months ago

In theory, ASP.NET with Session state enabled locks the session for each user request, thus processing them serially. I don't think you can disable Session for an MVC project painlessly, because TempData for example uses session by default. But you can try.

EDIT: here's a related question

Friday, August 20, 2021
Byron Whitlock
answered 4 Months ago

You need to add listeners when retrieving the url.

Please read the documentations

taskSnapshot.getDownloadUrl().addOnSuccessListener(new OnSuccessListener<Uri>() {
    public void onSuccess(Uri uri) {
        // Got the uri
        ImageUpload imageUpload = new ImageUpload(editText5.getText().toString(), uri.toString());
        // Wrap with Uri.parse() when retrieving

        String uploadId = mDatabaseRef.push().getKey();
}).addOnFailureListener(new OnFailureListener() {
    public void onFailure(@NonNull Exception exception) {
        // Handle any errors
Saturday, August 28, 2021
answered 3 Months ago

By default stdout and stderr are sent to /dev/null (nowhere) for android apps.

You can use adb setprop to set log.redirect-stdio to true, or put "log.redirect-stdio=true" in /data/local.prop (which you may need root access to create, but it's more reliable). Doing this will send their output to the logcat log.

See "Viewing stdout and stderr":

Monday, October 4, 2021
answered 2 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :