|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-12-09
请buaawh详细解释一下back buttone与session的关系，谢谢
|
| 返回顶楼 | |
|
发表时间：2005-12-09
即使session里面放置用户信息，也要考虑。只存放不变或由用户自己修改的信息，比如nickname等。可变信息比如帐户余额可能有管理员或系统逻辑修改，放在session中就失去意义了。
session中存放过多东西的确会给集群的session复制带来性能的影响。另外，最好将session中对象的ID同时存放于cookie中，这样就不需要依赖于集群的failover。比如基于session的购物车，shoppingcart中只存放productId和count, 至于具体product，则有全局的cache来管理。一旦用户被切换至另一服务器，可由cookie中的信息来恢复用户的shoppingcart。 tapestry，状态的persist可两种方式，session/client，各有利弊。 至于楼主的项目难题，我觉得是一个设计原则的问题，session的确可以缓存住一些状态，但是也不能完全依赖。比如常见的操作是，list出来了，detail干吗还要去访问一次数据库，直接利用存放于session中的list不就行了。但是如果： 1、list的数据量极大； 2、list -> session ->detail之间，其他用户修改了，你的依赖于session的detail就是dirty的。 在web中，session更多是用来保存用户状态的，不是用来保存持久数据的。减少db访问开销可以用其他的方式。 |
| 返回顶楼 | |
|
发表时间：2005-12-09
sorphi 写道 至于楼主的项目难题，我觉得是一个设计原则的问题，session的确可以缓存住一些状态，但是也不能完全依赖。比如常见的操作是，list出来了，detail干吗还要去访问一次数据库，直接利用存放于session中的list不就行了。 现在得项目里面就是这样做得，取出来得list是放再session里面，框架里面也设计了一个方法在每个功能结束得时候清空这个function的存放session里面的内容。但是client有可能他的这个功能没有全部做完就换到其它的function里面了，比如刚才说的有input －》 list －》 detail这样的流程 但是用户只做了前两步，根本就没有到最后所以这样的前面放到session里面的值就会存在，没有被及时清掉。（清session的方法在detail的时候才执行） sorphi 写道 但是如果： 1、list的数据量极大； 2、list -> session ->detail之间，其他用户修改了，你的依赖于session的detail就是dirty的。 至于你说的这种情况在detail的时候没有办法判断是否有用户修改了数据，但是在update，delete等方法的时候会有version Num来做check的。 |
| 返回顶楼 | |
|
发表时间：2005-12-09
killvin 写道 请buaawh详细解释一下back buttone与session的关系，谢谢
还是用前面那个例子。一个简单的例子。 1. 打开browser A, 访问 init page 查询, 这个时候session 里面存放了50条记录。 2. 换一个条件查询，这时候session里面替换上了 30条记录。 3. 用户突然觉得step 2 是错误的，还是应该使用step 1的结果，于是click back button 两次，回到 step 1的结果，然后选择一条进行check。 这个时候, server 端会用 session 里的 step 2 的30 条，来进行匹配。可能找不到step 1 结果里面check 的那一条。this operation is broken. |
| 返回顶楼 | |
|
发表时间：2005-12-09
buaawhl 写道 bluemeteor 写道 最近做MS passport的开发，发现他的sample code中pageFlow实际上是encrypted cookie实现的
我的目标是让所有的info脱离session，用好cookie和request可以满足需求 encrypted cookie 肯定是 双向解密加密，并非完全不可破解。而且要求客户浏览器打开对cookie的支持。 cookie的容量也是很有限的。而且传来传去, 也占用一部分带宽。 和URL Rewriting, Hidden input field 没有太大的区别。 需要缓存的比较多的数据，还是要放在server。就看放在哪里。session, or general cache. ^_^ cookie好只是相对于使用session来说得 例如多个web site下实现同一用户logon once time，除了cookie，没有找到更好得代替session同步机制的办法 至于cookie的客户端限制，有的客户端连JS或者swf都不支持 但是我们不能因此而放弃 无限通用需要无限代价 |
| 返回顶楼 | |
|
发表时间：2005-12-09
bluemeteor 写道 例如多个web site下实现同一用户logon once time，除了cookie，没有找到更好得代替session同步机制的办法
SSO? Single Sign On? 据我所知，只能用cookie实现。还不知道别的方法。 |
| 返回顶楼 | |
|
发表时间：2005-12-09
buaawhl 写道 killvin 写道 请buaawh详细解释一下back buttone与session的关系，谢谢
还是用前面那个例子。一个简单的例子。 1. 打开browser A, 访问 init page 查询, 这个时候session 里面存放了50条记录。 2. 换一个条件查询，这时候session里面替换上了 30条记录。 3. 用户突然觉得step 2 是错误的，还是应该使用step 1的结果，于是click back button 两次，回到 step 1的结果，然后选择一条进行check。 这个时候, server 端会用 session 里的 step 2 的30 条，来进行匹配。可能找不到step 1 结果里面check 的那一条。this operation is broken. 可是对于Http这样无状态的协议来说，是根本没有办法做到完全的"禁止"Back buttone这个功能。如果仅仅只是为了这个功能而在服务器端采用数据库的形式保存用户的Session信息，未免太牵强了点，而且从性能方面权衡，这个做法是不是代价太大了点？ 只是不知道buaawh有没有具体的数据说明你的这个方式在大数据量的情况下依然保持优秀的性能？Thanks |
| 返回顶楼 | |
|
发表时间：2005-12-09
killvin 写道 可是对于Http这样无状态的协议来说，是根本没有办法做到完全的"禁止"Back buttone这个功能。如果仅仅只是为了这个功能而在服务器端采用数据库的形式保存用户的Session信息，未免太牵强了点，而且从性能方面权衡，这个做法是不是代价太大了点？ wait ! “用数据库的形式保存用户的Session信息”? Where did i say it? 真是怪了，难道我的中文水平这么差，说的话 能引起这么多歧义？ 不是第一次了，不少这样的例子，根本和我无关的事情，都成我说的了。:D killvin 写道 只是不知道buaawh有没有具体的数据说明你的这个方式在大数据量的情况下依然保持优秀的性能？Thanks 首先确认一下，我提出的方式是，query cache. 你是说，query cache的性能？ 可以参考 hibernate 的 query cache. 我做的，lightor 的query cache 性能更好。不过还没有时间来得及准备演示数据什么的。 |
| 返回顶楼 | |
|
发表时间：2005-12-09
session中保留的应该是最重要的信息 比如客户状态 定单等等.
从数据库中取得的数据也放到session中是绝对不规范的 千万不要将session当内存数据库用 ! |
| 返回顶楼 | |
|
发表时间：2005-12-11
除了Back Button，还可以举个明显的比较极端的例子，来说明session state的不可靠。当然实际上，几乎没有人这么使用。
1. 你打开browser A, 访问 init page 查询, 这个时候session 里面存放了50条记录。 2. 你从Browser A new 一个新的browser B, 这个时候， browser A 和 browser B 共享一个session。 3. 你在 browser B的init page 用不同的条件查询，这个时候，session里面替换上了 30条记录。 4. 你回到browser A，继续Check，这时候，使用的是那30条记录。 ---- 不错 都是典型的和session有关的问题 可以归结成 back button/backspace问题 ctrl－N问题 我们做的方案是：简单的禁掉操作 其次，你的cache怎么保证用户强行中止浏览器/reset/connection fail的时候清空呢？ |
| 返回顶楼 | |
