State Server disadvatages

In Proc Session State is abadone in two casses: when Wroker Process Recycling or when session timeout.

I need to keep the sensitive session varaibles, where application depends on its existance. So I have done two things.

1开发者_JS百科- Make session timeout > Form Authentication timeout.

2- Use State Server. Using State server caused a performance problem so I used Cache to increase performance.

This is a part of CRM app, where Employee search for a customer, when found, the customer is loaded to Session state, then when Employee, navigates to any page, all pages know which customer we talk about. I think this approach is better than using encrypted QueryStrings.

What do u think? Is there something I miss?

Is there a better pradigm which helps the rest of architecture more?

Thanks

 public class ContextManager : Manager
    {

        private static Customer m_Customer;

        public static void LoadCustomer(int customerID)
        {

            if (customerID <= 0)
            {
                throw new ArgumentException("customer id should be >= 0");
            }

            m_Customer = CustomerManager.FindCustomerByID(customerID);
            HttpContext.Current.Session["Customer"] = m_Customer;
        }



        public static Customer Customer
        {
            get
            {


                if (m_Customer == null) // for performance.  the code visit this place very frequently in one http request
                {
                        CheckCustomerInSession();
                        m_Customer = HttpContext.Current.Session["Customer"] as EdaraFramework.DOC.Customer.Customer;
                }

                return m_Customer;
            }
        }

        private static void CheckCustomerInSession()
        {
            if (HttpContext.Current.Session["Customer"] == null)
            {
                // Pages accepted to have a null customer are default page and customer Search
                // , Customer Edit is where LoadCustomer is called.
                if ((!HttpContext.Current.Request.Path.Contains("Default.aspx")) 
                    && (!HttpContext.Current.Request.Path.Contains("CustomerSearch.aspx")))
                {
                    m_Customer = null;
                    HttpContext.Current.Response.Redirect("~/Default.aspx");
                }
            }
        }
    }

I think you might want to step back and really consider what you are doing.

"Using State server caused a performance problem..."

This is expected when using out of process sessions that are not stored in your web servers memory. Incidentally, it's one of the top reasons why I always advocate just shutting session off.

When you start adding web servers, session really breaks down. Further, most people tend to store a LOT of stuff in session not realizing that the servers have to spend time serializing and deserializing session data even when it's not used on the pages in question. When this data is stored on a third server in order to support web farms, the time spent is radically increased due to all of the network traffic. Further you go from a single failure point (the one web server) to multiple failure points (network, switch, cables, state server, etc).

See if you can just get rid of the session dependency entirely and move to using an encrypted ID in your query strings for grabbing customer details. Of course, you still need to validate that the user account has access to those customer details, but you should be doing that anyway.

This is a bad idea, you will get unexpected sharing of state among different users of your application and surprising resetting of your static fields when the app domain is unloaded. If you need session to live longer, use StateServer or Sql Session.

Note, that static members persist not only between roundtrips of the same session, but also between different sessions of the same application. This means that multiple users working in the same time will be working on the same objects.

Ref: http://www.velocityreviews.com/forums/t122181-static-fields-in-asp-net-pages.html

State Server is an in memory structure. I'd be surprised if it has performance issues. Sql Session writes to disk, so it does have a performance hit, but normally not large enough to notice. Was the State Server running, did you get a timeout error, or did page load times suddenly jump?

Performance issues are normally caused by long running stored procedures or excessively large number of stored procedure calls in one page.