62,046
社区成员
发帖
与我相关
我的任务
分享Session丢失
后台操作过程中,,,
Session无故丢失,有的时候是几十秒,有的是几分钟...
不大清楚是什么原因,,,IIS那边已经设置好是,是30分钟..
Web.config中,设置了为:
<sessionState mode="InProc" cookieless="false" timeout="30"/>
Session无故丢失,有的时候是几十秒,有的是几分钟...
不大清楚是什么原因,,,IIS那边已经设置好是,是30分钟..
Web.config中,设置了为:
<sessionState mode="InProc" cookieless="false" timeout="30"/>
...全文
请发表友善的回复…
发表回复
以专业开发人员为伍 2008-12-21
- 打赏
- 举报
?
anncesky 2008-12-12
- 打赏
- 举报
[Quote=引用 15 楼 pl1069 的回复:]
sp1234,zhnzzy写的很好，只是如果是在intranet中开发程序，需要长时间保持session怎么办？还有当超时时如何上用户知道和重新登录？
[/Quote]
----------------------------
长时间保持建议用cookie,当超时时，在用户不刷新的情况下可以这么做
在Global.asax文件里
void Session_End(object sender, EventArgs e)
{
Response.redirect("url");
}
不过这个代码有个前提就是
sessionState mode="InProc"这是必须的
sp1234,zhnzzy写的很好，只是如果是在intranet中开发程序，需要长时间保持session怎么办？还有当超时时如何上用户知道和重新登录？
[/Quote]
----------------------------
长时间保持建议用cookie,当超时时，在用户不刷新的情况下可以这么做
在Global.asax文件里
void Session_End(object sender, EventArgs e)
{
Response.redirect("url");
}
不过这个代码有个前提就是
sessionState mode="InProc"这是必须的
pl1069 2008-12-12
- 打赏
- 举报
sp1234,zhnzzy写的很好，只是如果是在intranet中开发程序，需要长时间保持session怎么办？还有当超时时如何上用户知道和重新登录？
supremeholy 2008-12-12
- 打赏
- 举报
学习了！
Jack123 2008-12-12
- 打赏
- 举报
up
以专业开发人员为伍 2008-12-08
- 打赏
- 举报
当你开发asp.net应用的时候，试一试在浏览器输入网站地址先访问网站的一些操作，然后手动地“停止”web服务器（对于vs自带的web服务器直接stop就可以，对于iis则是重新启动），然后继续在浏览器上访问网站。你的应用应该毫不受影响，没有什么会话数据看上去似乎“丢失了”，也不需要重新登录。把这个作为asp.net应用系统的开发检测标准是非常有实用意义的。
以专业开发人员为伍 2008-12-08
- 打赏
- 举报
最有欺骗性地是：当你在自己的机器上开发时几乎与不可能遇到这个问题，这个问题只在有很多网站同时运行的生产服务器上才出现。所以，你开发时有可能根本就无视这个问题的存在，而产品上线后又以为它只是“配置问题”应该很好解决。
实际上，靠配置根本解决不了这个问题。相反地，当asp.net系统运行到尚没有解决bug时，iis就会回收应用程序来“修复”系统bug。如果你的应用根本不使用Session来持久化保持数据，那么你的就会很欢迎这种机制的存在，因为这样你的服务器看上去就特被强壮从来不罢工。
实际上，靠配置根本解决不了这个问题。相反地，当asp.net系统运行到尚没有解决bug时，iis就会回收应用程序来“修复”系统bug。如果你的应用根本不使用Session来持久化保持数据，那么你的就会很欢迎这种机制的存在，因为这样你的服务器看上去就特被强壮从来不罢工。
ReyZhang 2008-12-08
- 打赏
- 举报
顶~~
yxwf2008 2008-12-08
- 打赏
- 举报
这个问题在开始接触NET的时候就碰到过，只可惜老师让俺自己去想，过了几天没想出来，再去问老师，老师说，呆会儿我帮你查查~！
狂晕
狂晕
accomp 2008-12-08
- 打赏
- 举报
学习了
zhnzzy 2008-12-08
- 打赏
- 举报
mode="InProc"
==
默认的配置方式很容易丢失Session 请参考
asp中Session的工作原理：
asp的Session是具有进程依赖性的。ASP Session状态存于IIS的进程中，也就是inetinfo.exe这个程序。所以当inetinfo.exe进程崩溃时，这些信息也就丢失。另外，重起或者关闭IIS服务都会造成信息的丢失。
原因1：
bin目录中的文件被改写，asp.net有一种机制，为了保证dll重新编译之后，系统正常运行，它会重新启动一次网站进程，这时就会导致Session丢失，所以如果有access数据库位于bin目录，或者有其他文件被系统改写，就会导致Session丢失
原因2：
文件夹选项中，如果没有打开“在单独的进程中打开文件夹窗口”，一旦新建一个窗口，系统可能认为是新的Session会话，而无法访问原来的Session，所以需要打开该选项，否则会导致Session丢失
原因3：
似乎大部分的Session丢失是客户端引起的，所以要从客户端下手，看看cookie有没有打开
原因4：
Session的时间设置是不是有问题，会不会因为超时造成丢失
原因5：
IE中的cookie数量限制（每个域20个cookie）可能导致session丢失
原因6：
使用web garden模式，且使用了InProc mode作为保存session的方式
解决丢失的经验
1. 判断是不是原因1造成的，可以在每次刷新页面的时候，跟踪bin中某个文件的修改时间
2. 做Session读写日志，每次读写Session都要记录下来，并且要记录SessionID、Session值、所在页面、当前函数、函数中的第几次Session操作，这样找丢失的原因会方便很多
3. 如果允许的话，建议使用state server或sql server保存session，这样不容易丢失
4. 在global.asa中加入代码记录Session的创建时间和结束时间，超时造成的Session丢失是可以在SessionEnd中记录下来的。
5. 如果有些代码中使用客户端脚本，如javascript维护Session状态，就要尝试调试脚本，是不是因为脚本错误引起Session丢失
问：为什么Session在有些机器上偶尔会丢失？
答：可能和机器的环境有关系，比如：防火墙或者杀毒软件等，尝试关闭防火墙。
问：为什么当调用Session.Abandon时并没有激发Session_End方法？
答：首先Session_End方法只支持InProc（进程内的）类型的Session。其次要激发Session_End方法，必须存在Session（即系统中已经使用Session了），并且至少要完成一次请求（在这次请求中会调用该方法）。
问：为什么当我在InProc模式下使用Session会经常丢失？
答：该问题通常是由于应用程序被回收导致的，因为当使用进程内Session时，Session是保存在aspnet_wp进程中，当该进程被回收Session自然也就没有了，确定该进程是否被回收可以通过查看系统的事件查看器获得信息。
具体信息请参考：
Session variables are lost intermittently in ASP.NET applications
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q316148
在1.0的时候也有一个bug会导致工作进程被回收并重启，该bug已经在1.1和sp2中修复。
关于该bug的详细信息请参考：
ASP.NET Worker Process (Aspnet_wp.exe) Is Recycled Unexpectedly.
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q321792
问：什么类型的对象可以保存在Session里？
答：这依赖使用的Session的模式，当使用的是进程内（InProc）的Session那么可以轻松的保存任何对象。如果你使用了非InProc的模式，则只能保存可以序列化和反序列化的对象，如果此时保存的对象不支持序列化，则不能保存到这种模式（非InProc）的Session里。
问：为什么在Session_End中不能使用Response.Redirect和Server.Transfer方法跳转页面？
答：Session_End是一个在服务器内部激发的事件处理函数。它是基于一个服务器内部的计时器的，在激发该事件时服务器上并没有相关的HttpRequest对象，因此此时并不能使用Response.Redirect和Server.Transfer方法。
问：在Session_End中是否可以获得HttpContext对象？
答：不行，因为这个事件并没有和任何的请求（Request）相关联，没有基于请求的上下文。
问：在Web Service中该如何使用Session？
答：为了在Web Service中使用Session，需要在Web Service的调用方做一些额外的工作，必须保存和存储调用Web Service时使用的Cookie。详细信息请参考MSDN文档的HttpWebClientProtocol.CookieContainer属性。然而，如果你使用代理服务器访问Web Service由于框架的限制，两者不能共享Session。
问：当我使用webfarm时，当我重定向到其他的Web服务器时Session为什么会丢失？
答：详细信息请参考：
PRB: Session State Is Lost in Web Farm If You Use SqlServer or StateServer Session Mode
http://support.microsoft.com/default.aspx?scid=kb;en-us;325056
问：Session在global.asax中的那些事件中有效？
答：Session只有在AcquireRequestState事件之后有效，该事件之后的事件都可以使用Session。
问：为了可以顺序访问Session的状态值，Session是否提供了锁定机制？
答：Session实现了Reader/Writer的锁机制：
当页面对Session具有可写功能（即页面有 <%@ Page EnableSessionState="True" %>标记），此时直到请求完成该页面的Session持有一个写锁定。
当页面对Session具有只读功能（即页面有 <%@ Page EnableSessionState="ReadOnly" %>标记），此时知道请求完成该页面的Session持有一个读锁定。
读锁定将阻塞一个写锁定；读锁定不会阻塞读锁定；写锁定将阻塞所有的读写锁定。这就是为什么两个框架中的同一个页面都去写同一个Session时，其中一个要等待另一个（稍快的那个）完成后，才开始写。
问：Session平滑超时意味着什么？
答：Session平滑超时意味着只要你的页面访问（使用）了Session，超时时间将被刷新（可以理解为重新计时），即从该页面请求开始，将重新计算超时时间。但是，该页面不能禁用Session。它会自动的访问当前页面的Session，刷新超时时间。
问：在global.asax中的事件处理函数中Session为什么无效？
答：依赖于在哪个事件处理函数中使用Session，Session在AcquireRequestState事件之后才有效，该事件之后的所有事件处理函数都可以使用Session，之前的则不能。
问：当我使用InProc模式保存Session时，此时的Session是保存在哪里？
答：不同的IIS的处理方式不同，
当使用的是IIS5的时候Session是保存在aspnet_wp.exe的进程空间里的。
当使用的是IIS6时，默认情况下所有的应用程序共享应用程序池，Session保存在w3wp.exe的进程空间中。
问：当页面出现错误后我的Session是否将被保存？我需要在Session_End中处理一些清理工作，但是失败了，为什么？
答：Session_End只有在Session运行在InProc模式下才会被执行。Session_End使用的帐号是运行aspnet_wp工作进程的帐号（这个可以在machine.config中设置）。因此，如果在Session_End方法里，使用集成安全性链接到SQL，它将使用aspnet_wp进程的帐号打开链接，此时成功与否则依赖于你的SQL的安全性设置。
问：在Session_End是我是否可以获得有效的HttpSessionState和HttpContext对象？
答：你可以在这个方法中获得HttpSessionState对象，可以直接使用Session来访问即可。但是不能获得HttpContext对象，因为该事件并没有和任何请求相关联，因此不存在上下文对象。
问：在SQLServer模式下使用Session，为什么我的Session不过期？
答：在SqlServer模式下，Session的过期是通过SQL Agent的注册工作完成的，请检查你的SQL Agent是否运行？
问：当我设置EnableSessionState为“ReadOnly”后，但是我在InProc模式下依然可以修改Session的值，这是为什么？
答：即使EnableSessionState标示为ReadOnly，但是在InProc模式下用户依然可以编辑Session。唯一不同的是，在请求过程中Session将不会被锁住。
问：为什么在切换成SQLServer模式后我的请求被挂起了？
答：检查在Session里面是否都保存的是可以保存在SQLServer模式下的对象，即这些对象必须支持序列化。
问：当Session设置成cookieless后会有什么影响？
答：当把cookieless设置成true时，主要会有下面的约束：
1、在页面中不能使用绝对链接
2、在应用程序中在除了Http和Https之间的切换时需要完成一些其他的步骤。
如果发送一个链接给其他人，此时的URL里面将包含Session ID的信息，所以两个人将公用一个Session。
==
默认的配置方式很容易丢失Session 请参考
asp中Session的工作原理：
asp的Session是具有进程依赖性的。ASP Session状态存于IIS的进程中，也就是inetinfo.exe这个程序。所以当inetinfo.exe进程崩溃时，这些信息也就丢失。另外，重起或者关闭IIS服务都会造成信息的丢失。
原因1：
bin目录中的文件被改写，asp.net有一种机制，为了保证dll重新编译之后，系统正常运行，它会重新启动一次网站进程，这时就会导致Session丢失，所以如果有access数据库位于bin目录，或者有其他文件被系统改写，就会导致Session丢失
原因2：
文件夹选项中，如果没有打开“在单独的进程中打开文件夹窗口”，一旦新建一个窗口，系统可能认为是新的Session会话，而无法访问原来的Session，所以需要打开该选项，否则会导致Session丢失
原因3：
似乎大部分的Session丢失是客户端引起的，所以要从客户端下手，看看cookie有没有打开
原因4：
Session的时间设置是不是有问题，会不会因为超时造成丢失
原因5：
IE中的cookie数量限制（每个域20个cookie）可能导致session丢失
原因6：
使用web garden模式，且使用了InProc mode作为保存session的方式
解决丢失的经验
1. 判断是不是原因1造成的，可以在每次刷新页面的时候，跟踪bin中某个文件的修改时间
2. 做Session读写日志，每次读写Session都要记录下来，并且要记录SessionID、Session值、所在页面、当前函数、函数中的第几次Session操作，这样找丢失的原因会方便很多
3. 如果允许的话，建议使用state server或sql server保存session，这样不容易丢失
4. 在global.asa中加入代码记录Session的创建时间和结束时间，超时造成的Session丢失是可以在SessionEnd中记录下来的。
5. 如果有些代码中使用客户端脚本，如javascript维护Session状态，就要尝试调试脚本，是不是因为脚本错误引起Session丢失
问：为什么Session在有些机器上偶尔会丢失？
答：可能和机器的环境有关系，比如：防火墙或者杀毒软件等，尝试关闭防火墙。
问：为什么当调用Session.Abandon时并没有激发Session_End方法？
答：首先Session_End方法只支持InProc（进程内的）类型的Session。其次要激发Session_End方法，必须存在Session（即系统中已经使用Session了），并且至少要完成一次请求（在这次请求中会调用该方法）。
问：为什么当我在InProc模式下使用Session会经常丢失？
答：该问题通常是由于应用程序被回收导致的，因为当使用进程内Session时，Session是保存在aspnet_wp进程中，当该进程被回收Session自然也就没有了，确定该进程是否被回收可以通过查看系统的事件查看器获得信息。
具体信息请参考：
Session variables are lost intermittently in ASP.NET applications
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q316148
在1.0的时候也有一个bug会导致工作进程被回收并重启，该bug已经在1.1和sp2中修复。
关于该bug的详细信息请参考：
ASP.NET Worker Process (Aspnet_wp.exe) Is Recycled Unexpectedly.
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q321792
问：什么类型的对象可以保存在Session里？
答：这依赖使用的Session的模式，当使用的是进程内（InProc）的Session那么可以轻松的保存任何对象。如果你使用了非InProc的模式，则只能保存可以序列化和反序列化的对象，如果此时保存的对象不支持序列化，则不能保存到这种模式（非InProc）的Session里。
问：为什么在Session_End中不能使用Response.Redirect和Server.Transfer方法跳转页面？
答：Session_End是一个在服务器内部激发的事件处理函数。它是基于一个服务器内部的计时器的，在激发该事件时服务器上并没有相关的HttpRequest对象，因此此时并不能使用Response.Redirect和Server.Transfer方法。
问：在Session_End中是否可以获得HttpContext对象？
答：不行，因为这个事件并没有和任何的请求（Request）相关联，没有基于请求的上下文。
问：在Web Service中该如何使用Session？
答：为了在Web Service中使用Session，需要在Web Service的调用方做一些额外的工作，必须保存和存储调用Web Service时使用的Cookie。详细信息请参考MSDN文档的HttpWebClientProtocol.CookieContainer属性。然而，如果你使用代理服务器访问Web Service由于框架的限制，两者不能共享Session。
问：当我使用webfarm时，当我重定向到其他的Web服务器时Session为什么会丢失？
答：详细信息请参考：
PRB: Session State Is Lost in Web Farm If You Use SqlServer or StateServer Session Mode
http://support.microsoft.com/default.aspx?scid=kb;en-us;325056
问：Session在global.asax中的那些事件中有效？
答：Session只有在AcquireRequestState事件之后有效，该事件之后的事件都可以使用Session。
问：为了可以顺序访问Session的状态值，Session是否提供了锁定机制？
答：Session实现了Reader/Writer的锁机制：
当页面对Session具有可写功能（即页面有 <%@ Page EnableSessionState="True" %>标记），此时直到请求完成该页面的Session持有一个写锁定。
当页面对Session具有只读功能（即页面有 <%@ Page EnableSessionState="ReadOnly" %>标记），此时知道请求完成该页面的Session持有一个读锁定。
读锁定将阻塞一个写锁定；读锁定不会阻塞读锁定；写锁定将阻塞所有的读写锁定。这就是为什么两个框架中的同一个页面都去写同一个Session时，其中一个要等待另一个（稍快的那个）完成后，才开始写。
问：Session平滑超时意味着什么？
答：Session平滑超时意味着只要你的页面访问（使用）了Session，超时时间将被刷新（可以理解为重新计时），即从该页面请求开始，将重新计算超时时间。但是，该页面不能禁用Session。它会自动的访问当前页面的Session，刷新超时时间。
问：在global.asax中的事件处理函数中Session为什么无效？
答：依赖于在哪个事件处理函数中使用Session，Session在AcquireRequestState事件之后才有效，该事件之后的所有事件处理函数都可以使用Session，之前的则不能。
问：当我使用InProc模式保存Session时，此时的Session是保存在哪里？
答：不同的IIS的处理方式不同，
当使用的是IIS5的时候Session是保存在aspnet_wp.exe的进程空间里的。
当使用的是IIS6时，默认情况下所有的应用程序共享应用程序池，Session保存在w3wp.exe的进程空间中。
问：当页面出现错误后我的Session是否将被保存？我需要在Session_End中处理一些清理工作，但是失败了，为什么？
答：Session_End只有在Session运行在InProc模式下才会被执行。Session_End使用的帐号是运行aspnet_wp工作进程的帐号（这个可以在machine.config中设置）。因此，如果在Session_End方法里，使用集成安全性链接到SQL，它将使用aspnet_wp进程的帐号打开链接，此时成功与否则依赖于你的SQL的安全性设置。
问：在Session_End是我是否可以获得有效的HttpSessionState和HttpContext对象？
答：你可以在这个方法中获得HttpSessionState对象，可以直接使用Session来访问即可。但是不能获得HttpContext对象，因为该事件并没有和任何请求相关联，因此不存在上下文对象。
问：在SQLServer模式下使用Session，为什么我的Session不过期？
答：在SqlServer模式下，Session的过期是通过SQL Agent的注册工作完成的，请检查你的SQL Agent是否运行？
问：当我设置EnableSessionState为“ReadOnly”后，但是我在InProc模式下依然可以修改Session的值，这是为什么？
答：即使EnableSessionState标示为ReadOnly，但是在InProc模式下用户依然可以编辑Session。唯一不同的是，在请求过程中Session将不会被锁住。
问：为什么在切换成SQLServer模式后我的请求被挂起了？
答：检查在Session里面是否都保存的是可以保存在SQLServer模式下的对象，即这些对象必须支持序列化。
问：当Session设置成cookieless后会有什么影响？
答：当把cookieless设置成true时，主要会有下面的约束：
1、在页面中不能使用绝对链接
2、在应用程序中在除了Http和Https之间的切换时需要完成一些其他的步骤。
如果发送一个链接给其他人，此时的URL里面将包含Session ID的信息，所以两个人将公用一个Session。
cranejuan 2008-12-08
- 打赏
- 举报
iis 的原因
以专业开发人员为伍 2008-12-08
- 打赏
- 举报
如果你是asp.net应用程序开发者，你去将问题归咎于网站管理员对你的网站目录多对应的应用程序设置了过低的回收监控指标？或者去责怪服务器有什么杀毒软件之类的？或者去责备asp.net系统和iis自身的异常回复机制？或者其它的几大类几百种可能性？这样真的就解决了问题了吗？
开发者应该接受这个网站现实。对于Session丢失现象说一千道一万也根本不能彻底解决这个问题，聪明者应该是首先寻找彻底解决问题之道，你去见招拆招地去找原因来“配置服务器”已经不适用于这个问题了。
开发者应该接受这个网站现实。对于Session丢失现象说一千道一万也根本不能彻底解决这个问题，聪明者应该是首先寻找彻底解决问题之道，你去见招拆招地去找原因来“配置服务器”已经不适用于这个问题了。
jiang_jiajia10 2008-12-08
- 打赏
- 举报
[Quote=引用 3 楼 sp1234 的回复:]
2年前我租过一个相当不错的空间（国内以及许多国家都有许多服务器），由于所选的型号交费不高（因此iis连接数、cpu占用率等指标不高），我的很少访问的asp.net程序大概12、13分钟之内就会重新回收一次。于是我将Session改为cookie管理，从此再也没有“丢失”过会话信息。
如果你使用iis7，你可以看到程序缓冲池的一个设置：
实际上，空间商会有软件来统一设置网站的更多的回收条件。
我就曾经让我的iis每隔1分钟回收…
[/Quote]
UP
2年前我租过一个相当不错的空间（国内以及许多国家都有许多服务器），由于所选的型号交费不高（因此iis连接数、cpu占用率等指标不高），我的很少访问的asp.net程序大概12、13分钟之内就会重新回收一次。于是我将Session改为cookie管理，从此再也没有“丢失”过会话信息。
如果你使用iis7，你可以看到程序缓冲池的一个设置：
实际上，空间商会有软件来统一设置网站的更多的回收条件。
我就曾经让我的iis每隔1分钟回收…
[/Quote]
UP
以专业开发人员为伍 2008-12-08
- 打赏
- 举报
2年前我租过一个相当不错的空间（国内以及许多国家都有许多服务器），由于所选的型号交费不高（因此iis连接数、cpu占用率等指标不高），我的很少访问的asp.net程序大概12、13分钟之内就会重新回收一次。于是我将Session改为cookie管理，从此再也没有“丢失”过会话信息。
如果你使用iis7，你可以看到程序缓冲池的一个设置：
实际上，空间商会有软件来统一设置网站的更多的回收条件。
我就曾经让我的iis每隔1分钟回收一次，以此来测试那些asp.net应用程序会话管理问题到底有没有可靠性。有些人说遇到这正问题就要千方百计地去检查服务器的“问题”，我认为这根本不是技术问题，由开发者去“解决”这个问题是从一开始就找错了方向。
如果你使用iis7，你可以看到程序缓冲池的一个设置：
实际上，空间商会有软件来统一设置网站的更多的回收条件。
我就曾经让我的iis每隔1分钟回收一次，以此来测试那些asp.net应用程序会话管理问题到底有没有可靠性。有些人说遇到这正问题就要千方百计地去检查服务器的“问题”，我认为这根本不是技术问题，由开发者去“解决”这个问题是从一开始就找错了方向。
yutian1225 2008-12-08
- 打赏
- 举报
应该还是iis 的原因
wuyq11 2008-12-08
- 打赏
- 举报
参考
http://www.cnblogs.com/nick-fbx/archive/2008/11/14/1333244.html
http://www.cnblogs.com/lihuanhuan/archive/2008/06/20/1227077.html
http://www.cnblogs.com/nick-fbx/archive/2008/11/14/1333244.html
http://www.cnblogs.com/lihuanhuan/archive/2008/06/20/1227077.html
