较合适。
完全不采用SesstionState
完全不采用SesstionState是在Web.config中写上
或者
enableSessionState=”Off”/>来禁止SessionState。那整个应用的所有页面都不会用SessionState。其实这不全面,http请求处理周期里还有一个系统默认的httpmodule在处理SessionState。还
须在Web.config加一句:
应用程序里完全不采用ASP.NET本身提供的SessionState机制,但是应用的需求是要求应用程序有类似于Session的机制的。比如购物车的概念。记住用户选择了哪些商品,在用户点了买单时才处理用户选择了的商品。如果不用ASP.NET本身提供的SessionState机制,就必须自己实现一个Session机制。比如可以在数据库中有一张表来记录自定义的Session数据。如果用户浏览器支持cookie,可以用该cookie存储自定义的Session
ID值。这个Session ID值用于到数据库中去查询存储的Session数据。如果用户浏览器不支持cookie,那么就可以在页面中放置隐藏的字段(hidden
field)。此隐藏字段用于存储自定义的Session
ID。还可以用URL中参数放一个Session参数的办法。这样获得的Session机制是自己管理的Session机制。需要将Session的创建,过时失效,查询Session数据,删除旧Session等都管理起来。
这样的自定义的Session机制将Session数据存储到了数据库。那么就可以不依赖与某一台具体的服务器。从而获得的可伸缩的特性。
采用SessionState
采用SessionState是ASP.NET默认的机制。ASP.NET的SessionState有几种模式。InProc,StateServer,SqlServer模式和自定义模式。InProc不支持负载均衡的场景。只有StateServer和SqlServer模式才支持。自定义模式是指我们自己实现Session数据的持久化,比如将Session数据放到Oracle数据库或者MySql数据库中,自定义模式也可以支持负载均衡。在StateServer和SqlServer模式时,放入Session中的数据都必须是能序列化的。建议采用SqlServer模式的Session机制。配置是这样的:
sqlConnectionString=" sql connection string " stateNetworkTimeout=" number of seconds " >Session采用了SqlServer模式之后,所有数据都会经序列化,并存储到SqlServer数据库中。采用这种模式的Session机制,其Session可以由任何一个UI排Tier的服务器来处理,因为Session数据是存储在专门的数据库中的。如果是采用这种模式的Session机制,那么最好有专门的数据库服务器供存储Session数据。通过上述安排,ASP.NET应用就获得了负载均衡,可伸缩的能力。
采用了ASP.NET的SessionState的之后,同一个Session ID下的不同页面请求会有一定的制约。注意这里说的同一个Session
ID下的不同页面。这就象数据库的锁机制一样。默认的ASP页面设置都是能对Session对象进行读和写
。那么如果同一个Session
ID的两个不同请求访问两个不同的页面,就会因为都去锁住Session对象,而造成有一个请求被阻塞较长时间,因为要等另一个请求处理完毕。有同仁可能觉得奇怪,怎么会有同一个Session
ID请求两个不同的页面。其实这与页面中的iframe,frameset和A