我应该如何依赖是对会议 [英] How reliant should I be on Session
问题描述
我使用的会话做两件事情：
I am using session to do two things:
- 跟踪哪个CSS文件加载特定的公司。
- 跟踪公司标识的Guid，跟踪我们是什么公司。
我看到了，这是作为null有时来了，但我没有得到一致的问题追查。我毫不怀疑这可能是东西在我的code，我需要追查但是这给我带来了我的有关会话的问题...
I am seeing that this is coming in as null sometimes but I'm not getting a consistent problem to track down. I have no doubt this is probably something in my code that I need to track down but this bring me up to my questions about session...
- 是我依靠会话得多传递屏幕之间的信息？
- 是不是一致的？
- 有什么能页面加载之间结算呢？
- 是会议通过的用户很容易被清除？
- 我应该使用其他更可靠的东西吗？
我很担心，我会提出这个活的使用，并有各种问题。
I am worried that I will move this to live usage and have all kinds of problems.
我只是这样做：
Session["Css"] = css;
和阅读它以同样的方式：
and reading it the same way:
css = Session["Css"]
更新
我使用的会话：
HttpSessionStateBase控制器会话
HttpSessionStateBase Controller Session
推荐答案
有几种类型的会话状态。是InProc，的StateServer，和SqlServer。我相信，默认为是InProc。你可以阅读更多有关这在MSDN上这里和这里。
There are a few types of Session State. InProc, StateServer, and SqlServer. I believe the default is InProc. You can read more about this on MSDN here and here.
每个这些都将服从你的web.config文件中定义的sessionState超时值。对于单个服务器设置（这是我通常是这样）我通常有我的sessionState设置如下：
Each of these will obey the timeout value for sessionState defined in your web.config file. For a single server setup (which is what I typically do) I usually have my sessionState setup as follows:
<sessionState
mode="StateServer"
stateConnectionString="tcpip=127.0.0.1:42424"
timeout="2880" />
这是因为窗体身份验证，所以我的会议将只要坚持围绕我的用户身份验证的Cookie /会话相同的默认超时。这需要你设置ASP.NET状态服务器上启动到自动。下面是我的高层次的通在解释类型及其潜在的缺点。
This is the same default timeout as Forms Auth, so my sessions will stick around as long as my users auth cookie/session. This will require you to set the start up on the ASP.NET State Server to Automatic. Below is my high-level pass at explaining the types and their potential drawbacks.
这将重置每次应用程序池回收的web应用程序的工作进程。我相信这是发生了什么事给你，这就是为什么你的会话变量是在什么似乎是随机的时间空。
This will be reset everytime the application pool recycles the worker process for the web app. I believe this is what is happening to you, and this is why your session variables are null at what appear to be random times.
这将持续整个状态再循环程序池，但是要求您启用ASP.NET状态服务器服务，并改变它的启动类型设置为自动。
This will persist state across apppool recycles, but requires that you enable the ASP.NET State Server Service, and change it's start up type to Automatic.
您可以碰到的问题，如果你有一个Web场或多个Web服务器处理的网站，除非你运行一个专用的状态服务器。
You can run into issues if you have a web farm or multiple web servers handling the website, unless you run a dedicated state server.
这要求存储在会话变量变量 [Serializable接口] 。
This requires that variables stored in session variables are [Serializable].
这将持续会话变量到SQL数据库，一般是一个Web场的情况，最好的办法。
This will persist session variables to a SQL database, and is is generally the best approach for a web farm situation.
这要求存储在会话变量变量 [Serializable接口] 。
This requires that variables stored in session variables are [Serializable].
这篇关于我应该如何依赖是对会议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
