Hopes

Start Here..

 

session时不时就会过期?

1、问题现象:有个网站是通过session验证的,前端时间访问正常,但近期后台session老是失效很快,根本没法操作,我设置timeout不管用,刷新页面就退出到登陆框,本测试机全部通过,好像是空间有问题,因为最强空间有过更新系统或者打补丁的动作,但空间技术说没问题,也有其他站点运行在同一服务器上,都是好的。 
2、解决办法:
经过耐心请求空间商其他技术,问题找到,是空间iis默认回收进程的内存太少,加大点就可以了!


---------------------------------------
附:相关问题
(一)、关于iis6中Session超时问题,后台几秒就自动退出解决办法
iis6中Session超时,后台登录后没过多久就自动退出问题,是IIS6中存在的问题,IIS5不会有这个问题,
即使你设置了Session.Timeout=999,还是会自动退出的
*建议把Session登录和验证方式改为Cookies登录和验证方式
原Session登录方式
Session("Name") =   rs("UserName")
改为
Response.Cookies("xmnet")("Name")=rs("UserName")
每个页面验证是否登录改为
if request.Cookies("aitoot")("Name")="" then
Response.Redirect ("Login.asp")
end if

--------------------------------------------
(二)、设置Session永不过期,Session有效时间的问题
保持Session的方法:有人说设session.timeout=-1,或小于0的数。这种方法肯定是不行的,session计算时间以分钟为单位,必须是大于等于1的整数。又有人说设session.timeout=99999。这种同样不行,session有最大时间限制。我经过测试发现最大值为24小时,也就是说你最大可以session.timeout=1440,1441都是不可以有,呵呵。本人测试环境:win2003+IIS6.0+ASP3.0。

所以想通过设session.timeout的过期时间让session永不过期是不可能的。写到Cookies里是比较好的方法,网上也有很多这样的教程,这里就不再说了!还有就是用在要保持session的页里设隐藏iframe每隔一段时间(这个时间小于session.timeout的时间)把刷新一次frame里的空页面!实现方法如下:

在要保持session页里加上: <iframe width=0 height=0 src="/blog/SessionKeeper.asp">
</iframe> 


同目录下建一下SessionKeeper.asp的文件。 <html>
<head>
<meta http-equiv="Refresh" content="900000;url=sessionKeeper.asp"> 
<!--每隔900秒刷新一下自己,为了和服务器通讯一下,保持session不会丢-->
</head>
</html>



这种方法还是比较长见的,另外还有一种和上面类似的方法,不过他不是用meta自动刷新嵌套的iframe的方法。他是用javascript:window.setTimeout("functionname()",10000);第隔一段时间时间自动调用一个函数的方法,当然函数里还是要去连接一个空的文件。具体方法如下:

在要保持session面里加上: <script id=Back language=javascript></script>

<script language=javascript>
function keepsession(){
document.all["Back"].src="/blog/SessionKeeper.asp?RandStr="+Math.random();
//这里的RandStr=Math.random只是为了让每次back.src的值不同,防止同一地址刷新无效的情况
window.setTimeout("keepsession()",900000); //每隔900秒调用一下本身
}
keepsession();
</script>


这样同一目录下建一个空内容的sessionKeeper.asp就文件就可以了!

问题没有解决:通过以上的方法Session保持应该没有问题了,IIS默认无请求的清除session的值为20分钟,我设的每次交互服务的时间都远远小于这个值,可是我大概过个一天多的时间,session还是无缘无故的没了!郁闷。

后来在网上多方查找终于找到答案:原来IIS为了保护服务器,有一个“回收”的概念!测试了半天终于有了点大体了解(不要笑我菜^-^)。先来看看这个“回收”在哪设置。

启动IIS管理器->应用程序池->右键->属性->回收选项卡,有一项是默认就起作用的,就是第一项:“回收工作进程(分钟)”默认值1740分钟,大约29个小时。他是什么意思呢?我个人理解:在session.timeout之后再过1740分钟自动把所有仍在保持的session清除。这个值最大可设为4000000,大概是2700多天!我直接取消了,不用他自动回收!问题终于解决。

另外这个属性对话框中还有其它几项:

第二项应该是连接的用户超过了一定数目回收。

第三项是到某一个时间就自动回收。

在“性能”选项卡中“在空闲此时间段后关闭工作进程”,这里就是设置IIS默认session.timeout时间的地方了。默认值20分钟,这里同样最大值可设为4000000,和在ASP页中设置session.timeout最大值为1440不同。在这里设置超过大于1440的值是否起作用,我没作测试,我想应该是可以的。那为什么在ASP页中session.timeout的值最大只能是1440在IIS的属性中却能设的那么大呢?应该是属于一种保护机制:ASP页的session.timeout的值哪个用户都可以设,IIS里却只有管理员可以设,两者的权限不同,所以设置的范围就不同了。

原文地址:http://www.5dblogo.com/article/session.htm

Session对象失效的客户端解决方法 

问题的提出 
ASP(Active Server Pages)技术的Session对象用于存储用户在对话期间的私有信息。当前用户的Session对象中定义的变量和对象能在页面之间共享,但是不能为应用中其他用户所访问,因此在用ASP开发网络应用程序时,可以利用Session对象保存和跟踪用户的状态信息。 
Session对象有一个十分重要的属性:Timeout,它用于设置在会话资源被释放前,会话对象所能保持非活动状态的时间(默认值为20分钟)。当Timeout属性设置的时间值耗尽后,会话资源将被释放。通过Timeout属性破坏Session对象,避免了Session对象在服务器中无限制地产生,保护了服务器资源。但是,在实际网络开发中,常常遇到由于Session对象失效,用户状态信息丢失而导致应用流程无法正常完成的问题。 
虽然利用Timeout属性释放资源的策略是出于保护服务器的目的,但是Session对象不可预知的失效性,却成为开发应用程序的一个弊病。因而在实际应用程序的开发中,必须解决Session对象失效的问题。 
传统的解决方法 
现有的解决方法都是采用服务器端方法解决Session对象失效问题。典型的处理方法分为两大类:失效前的处理和失效后的处理。 
失效前的处理是指在Session对象尚未失效之前,对变量进行转存等处理,做到防患于未然。典型的解决方法是在应用程序中设定一个定时器,在Session对象失效前5分钟触发定时器,然后重新设置Session对象的各个变量和对象。由于必须在服务器端实时维护该定时器,并且必须保证该段程序在整个会话过程中处于激活状态,所以采用这种方法增加了服务器的额外负载。 
失效后的处理是指在Session对象失效后,立即提示用户进行处理。典型的解决方法是在Session对象失效后,在服务器端保存断点,并提示用户重新登录,继续完成工作。这种方法实现简单,但是往往因为断点的不可完全自动恢复性,以及重新登录过程的复杂性,而受到最终用户的抱怨和指责。 
针对以上两类解决方案的缺陷,笔者在编程实践中结合Cookie对象的特性,采用Session对象与Cookie对象在客户端联合存取会话级变量的方法,既避免了对服务器资源的额外需求,又解决了断点不可自动恢复的问题,而且还免去了重新登录的麻烦。 
新的解决方法 
Cookie对象是用来存储有关当前用户数据的小信息包,它可以在浏览器和Web服务器之间传递。在Web应用中,Cookie提供了一种用于跟踪、记录每个用户位置的机制。Cookie最常见的用处之一,就是保存一个Web应用中最后一次被访问的网络页面的时间以及日期或被访问的网址。 
通常,Cookie对象在客户端Windows系统目录下Cookies子目录中以文件形式存储。存储在Cookie对象中的信息数据能够被保存较长时间,所以,可以将会话级变量备份在Cookie对象中,在Session对象失效后,通过检索并利用Cookie对象中的信息来自动恢复断点。 
Cookie对象具有如下几个属性: 
●Expires:设定Cookie对象到期的日期; 
●Domain:将Cookie对象的传送确定为仅由Domain属性确定的成员; 
●Path:确定Cookie对象传送路径; 
●Secure:明确Cookie对象是否安全; 
●HasKeys:返回Cookie对象是否包含多值。 
如果没有显式定义Cookie对象的Expires属性,Cookie对象将在用户会话期结束时到期。 
ASP中通过Request集合和Response集合读写对象。向Cookie对象写变量的语法如下: 
Response.Cookies(cookie)[(Key)|.attribute] = value 
其中,cookie是Cookie文件名,Key标明一个字典元素,attribute是Cookie 的一个具体性质,value是分给cookie的值。例如,为创建一个叫MyHobby的Cookie,并分配其值为:BasketBall,使用下述语法: 
<%Response.Cookies("MyHobby")="BasketBall" %> 
在客户机器上读取Cookie对象的方法如下: 
Request.Cookies(cookie)[(Key)|.attribute] 
其中,cookie是被请求Cookie的名字,Key是子关键字值下标,attribute是用于标明Cookie属性。例如:为抽取一个叫做MyHobby的Cookie中的信息并将它的值写到页面,使用下述语法: 
<% Request.Cookies("MyHobby") %> 
需要注意的是:不能在HTTP页首信息已被送到请求浏览器之后,再向一个Cookie对象写入信息。换句话说,不能在任何HTML标识符被发送到浏览器之后才向浏览器发送Cookie信息。 
具体实现 
下面通过一个基于ASP技术的聊天室的实现,来介绍如何处理Session对象变量失效的问题。 
●在用户登录前初始会话级变量:UserName(用于存储登录用户名)。 
<% Session("UserName")="" %> 
//初始化Cookie对象 
<% Response.Cookies("UserName")="" %> 
●在用户登录时,设置会话级变量并备份到客户端Cookie对象中。 
<%userName=Trim(Request.For("UserName"))%> 
<% Session("UserName")=userName %> 
//将会话级变量备份到客户端Cookie对象中 
<% Response.Cookies("UserName")=userName %> 
●在用户发言的时候,读取会话级变量,如果该变量已经失效,则通过读取Cookie对象,恢复该会话级变量的属性值。 
<% userName=Session("UserName") %> 
//如果变量已经失效,则检索客户端Cookie对象 
<% if userName="" then %> 
<% userName=Request.Cookies("UserName") %> 
<% if userName="" then %> 
//如果用户未经过登录就进入聊天室,则该Cookie对象属性值为空。此时,提示用户出错,并转向用户登录页面 
<% Response.Redirect "Error.html" %> 
<% else %> 
//从Cookie对象中恢复该会话级变量 
<% Session("UserName")=userName %> 
<% end if %> 
<% end if %> 
●当用户退出聊天室时,清除会话级对象和Cookie对象。 
<% Session(“UserName")="" %> 
//将Cookie对象属性值清除,避免用户不经过登录就直接进入聊天室 
<% Response.Cookies(“UserName")="" %> 
以上代码在Windows NT 4.0+IIS 4.0+IE 5.0环境中运行通过。 
小 结 
Session对象与Cookie对象在客户端联合存取会话级变量的方法简单实用,并且能够有效地避免用户强行登录等问题,不失为一种较好地解决Session对象失效的客户端方法。

原文地址:http://www.leadbbs.com/MINI/default.asp?230-2426882-0-0-0-0-0-a-.htm


Session的生存期并不是完全由你设定的timeout超时期限来决定的,在InProc的方式下,它受到的影响是多方面的,IIS,内存,CLR的垃圾回收都会影响到Session的存在,所以如果你以InProc的方式使用Session,就不要对它的可靠性存在什么幻想。   当然在.net下还有状态托管和SQLSERVER两种模式来实现对Session的控制,前一种方式,速度很慢,不同机器间的访问,要解析和穿越的协议比较多;SQLSERVER模式的速度介于两者之间,但可靠性是三者中最好的,如果你愿意牺牲一点访问速度而保持其可靠性的话,就选用SQLSERVER模式吧。

posted on 2012-07-30 13:00 ** 阅读(1985) 评论(0)  编辑  收藏


只有注册用户登录后才能发表评论。


网站导航:
 

导航

统计

公告

你好!

常用链接

留言簿(2)

随笔档案

文章分类

文章档案

新闻档案

相册

收藏夹

C#学习

友情链接

搜索

最新评论

阅读排行榜

评论排行榜