Strange behavior of UpdatePanel with Session and ViewState

Good morning,

There are many more WTF questions than any other question.

My application is using ViewState . I have placed the UpdatePanel in my application, which is purely for testing purposes. All it does is click my log table every time and create a live log console to see how the app is handling things.

This morning I decided to switch my use of ViewState to session . Now my UpdatePanel no longer runs synchronously and "pauses" until an operation is performed to update the UpdatePanel / Console.

Switching back to ViewState makes everything work fine ...

Also, the functions that my UpdatePanel calls are not related to ViewState or SessionState and do not call either ...

I was able to reproduce this behavior in a small test sample:

TestUpdatePanelWithSession.Master

<%@ Master Language="C#" AutoEventWireup="true" CodeBehind="TestUpdatePanelWithSession.master.cs" Inherits="Tester2._0.TestUpdatePanelWithSession1" %>

<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
    <asp:ContentPlaceHolder ID="head" runat="server">
    </asp:ContentPlaceHolder>
</head>
<body>
    <form id="form1" runat="server">
        <asp:ScriptManager ID="ScriptManager1" runat="server"></asp:ScriptManager>
        <asp:Timer ID="Timer1" runat="server" Enabled="True" Interval="1000"></asp:Timer>
        <div>
            <asp:ContentPlaceHolder ID="ContentPlaceHolder1" runat="server">
            </asp:ContentPlaceHolder>
        </div>
        <asp:UpdatePanel ID="UpdatePanel1"
            UpdateMode="Always"
            runat="server">
            <Triggers>
                <asp:AsyncPostBackTrigger ControlID="Timer1" EventName="Tick" />
            </Triggers>
            <ContentTemplate>

                <%= System.DateTime.Now.ToString("mm:ss") %>

                    </div>
            </ContentTemplate>
        </asp:UpdatePanel>
    </form>
</body>
</html>

      

TestUpdatePanelWithSession.aspx

<%@ Page Title="" Language="C#" MasterPageFile="~/TestUpdatePanelWithSession.Master" AutoEventWireup="true" CodeBehind="TestUpdatePanelWithSession.aspx.cs" Inherits="Tester2._0.TestUpdatePanelWithSession" %>

<asp:Content ID="Content1" ContentPlaceHolderID="ContentPlaceHolder1" runat="server">
    <asp:Label ID="lblTest" runat="server" Text="Label"></asp:Label>
    <asp:Button ID="btnStartTest" runat="server" Text="Test" OnClick="btnStartTest_Click" />
</asp:Content>

      

TestUpdatePanelWithSession.aspx.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Tester2._0
{
    public partial class TestUpdatePanelWithSession : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            if (!Page.IsPostBack)
            {
                Session["SomeIndex"] = 50000;
            }
        }

        protected void btnStartTest_Click(object sender, EventArgs e)
        {
            for (int i = 0; i < 1000000; i++)
            {
                System.Threading.Thread.Sleep(500);
                Session["SomeOtherIndex"] = i;

                lblTest.Text = ((int)Session["SomeIndex"] + (int)Session["SomeOtherIndex"]).ToString();
            }
        }
    }
}

      

The above code works great if you change the whole session to ViewState. What the hell is going on?

Thanks in advance for the lesson ...

+3


source to share


1 answer


After testing the example, it turns out that the problem stems from the readwrite blocking from the session.

Removing the session usage from Page_Load avoids this behavior, but it's a bit weird since the code doesn't hit when the refresh bar calls the page. Even moving code to another function, calling it on another thread, or using a task does not prevent this behavior.



ASP.net seems to parse the code and when there is code using the session, even if not executing, it locks the session, which prevents the callbacks from executing normally. Leaving only session manipulation on control events seems to work fine.

The only solution for what I've tested is to remove the Page_Load session manipulation, which may be unavoidable in some scenarios.

+3


source







All Articles