81,091
社区成员
发帖
与我相关
我的任务
分享查询后分页，数据放在session中，操作N次后很卡？
如题，查询后实现分页效果，把数据放在session中。
查询几次后就会出现卡死状态...
每次更换查询时都用session.removeAttribute("files"); 清除。
这种情况怎么办啊？有需要注意的地方么？
查询几次后就会出现卡死状态...
每次更换查询时都用session.removeAttribute("files"); 清除。
这种情况怎么办啊？有需要注意的地方么？
...全文
请发表友善的回复…
发表回复
「已注销」 2012-08-10
- 打赏
- 举报
如果不用session的话、我要是编辑分页数据中的某一条具体的信息、、那就必须根据信息ID重新在库里查么、
lei4526454 2011-07-01
- 打赏
- 举报
半年了 ！我给你解决！！！查询时用回调函数！！！这样查询N次！！永远不会卡死！！！
wb57205375 2011-01-09
- 打赏
- 举报
struts2中文本框会自动保留查询条件，点击下一页按钮时把文本框中的查询条件传到action中即可。
wb57205375 2011-01-07
- 打赏
- 举报
哦 试试楼上的方法
wangjiangbo2 2011-01-07
- 打赏
- 举报
你可以把查询条件回填啊，每进一页就重新查询（参数要加上页码和每页记录数）。
如果点下一页要传结果，可以通过request.setAttribute("list",list)传递
如果点下一页要传结果，可以通过request.setAttribute("list",list)传递
wb57205375 2011-01-07
- 打赏
- 举报
[Quote=引用 29 楼 hzzduoduo 的回复:]
分页不用放在session中吧 没有那个必要的
[/Quote]
查询后的分页！
普通分页，调用查询方法，然后传入页码，实现先分页效果。这个好弄。
但是查询后分页，是有查询条件的，一点下一页，文本框中的查询条件都没了，查出的数据就变成所有数据的
下一页了...
分页不用放在session中吧 没有那个必要的
[/Quote]
查询后的分页！
普通分页，调用查询方法，然后传入页码，实现先分页效果。这个好弄。
但是查询后分页，是有查询条件的，一点下一页，文本框中的查询条件都没了，查出的数据就变成所有数据的
下一页了...
hzzduoduo 2011-01-07
- 打赏
- 举报
分页不用放在session中吧 没有那个必要的
wb57205375 2011-01-07
- 打赏
- 举报
[Quote=引用 26 楼 wy100304441 的回复:]
查询条件你可以让他保留的嘛。
保留查询条件的方法就很多种了。
[/Quote]
比如说？
查询条件你可以让他保留的嘛。
保留查询条件的方法就很多种了。
[/Quote]
比如说？
wb57205375 2011-01-07
- 打赏
- 举报
[Quote=引用 25 楼 wb57205375 的回复:]
关键是一点下一页，查询条件就都没了，翻到下一页后，数据就变成无条件查询出来的所有数据了...
[/Quote]
比如说？
关键是一点下一页，查询条件就都没了，翻到下一页后，数据就变成无条件查询出来的所有数据了...
[/Quote]
比如说？
骑着狼看狮子丶 2011-01-06
- 打赏
- 举报
查询条件你可以让他保留的嘛。
保留查询条件的方法就很多种了。
保留查询条件的方法就很多种了。
wb57205375 2011-01-06
- 打赏
- 举报
关键是一点下一页，查询条件就都没了，翻到下一页后，数据就变成无条件查询出来的所有数据了...
wang1986614 2011-01-04
- 打赏
- 举报
建议最好不要把查询的结果集放到session中，改成其他的方法吧！
jklot66 2011-01-04
- 打赏
- 举报
[Quote=引用 20 楼 wb57205375 的回复:]
放在request中行不通啊，因为是查询后的分页，你一点下一页，查询条件就都没了。
所以session中不放List<files>，至少也得放个Hql语句来保存查询条件。
保存HQL应该可以节省很多内存。
[/Quote]
查询的分页信息你多翻几页 session就会保存上百条记录了
session的对象都是存在内存中的，所以翻不了几页就很卡了
查询条件你可以放在request的属性中，页面在获取出来填写即可。
放在request中行不通啊，因为是查询后的分页，你一点下一页，查询条件就都没了。
所以session中不放List<files>，至少也得放个Hql语句来保存查询条件。
保存HQL应该可以节省很多内存。
[/Quote]
查询的分页信息你多翻几页 session就会保存上百条记录了
session的对象都是存在内存中的，所以翻不了几页就很卡了
查询条件你可以放在request的属性中，页面在获取出来填写即可。
ladybirds2008 2011-01-04
- 打赏
- 举报
[Quote=引用 8 楼 bolink5 的回复:]
这种做法是可以的 一般数据量少是无所谓的
当数据量达到几十W、几百W就直接报内存溢出了
根据系统来定的吧
[/Quote]
这种做法是可以的 一般数据量少是无所谓的
当数据量达到几十W、几百W就直接报内存溢出了
根据系统来定的吧
[/Quote]
wb57205375 2011-01-04
- 打赏
- 举报
放在request中行不通啊，因为是查询后的分页，你一点下一页，查询条件就都没了。
所以session中不放List<files>，至少也得放个Hql语句来保存查询条件。
保存HQL应该可以节省很多内存。
所以session中不放List<files>，至少也得放个Hql语句来保存查询条件。
保存HQL应该可以节省很多内存。
热带鱼2020 2011-01-04
- 打赏
- 举报
其实只需要记录当前页码，每页显示的条数就可以了
这些都可以用hidden实现
这些都可以用hidden实现
elmnd 2011-01-03
- 打赏
- 举报
[Quote=引用 10 楼 telome 的回复:]
一般查询结果都是放在request里面的！
[/Quote]
或者用AJAX，OSCACHE等缓存吧。真的不要用SESSION。
一般查询结果都是放在request里面的！
[/Quote]
或者用AJAX，OSCACHE等缓存吧。真的不要用SESSION。
czl923 2011-01-03
- 打赏
- 举报
数据量大的话用数据库分页吧，
而且页码、页数和当前页等信息没必要存session吧，直接显示出来不就行了。
而且页码、页数和当前页等信息没必要存session吧，直接显示出来不就行了。
Ku_wan 2011-01-03
- 打赏
- 举报
没必要吧？数据直接放在Session中？真不敢想象呀！其实只需要记录当前页码，每页显示的条数就可以了！这些都可以用hidden实现呀。我最近就在做分页的项目。
建议你看看韩顺平的分页，简单明了易懂！入门然后到请G大神找资料进阶。
建议你看看韩顺平的分页，简单明了易懂！入门然后到请G大神找资料进阶。
火龙果被占用了 2011-01-02
- 打赏
- 举报
严禁在 HttpSession 中塞分页数据！下面这些是原来在一个帖子中的回复，有兴趣的话可以看一下：
http://topic.csdn.net/u/20100102/10/3580fea8-53af-4c6b-b410-e9a665eb8f3e.html
9 楼、11 楼
Session 在 Servlet 容器 Tomcat 中的存储结构是这样的：
HashMap<SessionId, Hashtable<SessionKey, SessionValue>>
其中
SessionId 是 Servlet 容器为当前 Session 分配的一个唯一值
SessionKey 是某 Session 中的 key 值，也就是使用 session.setAttribute 方法参数的第一个值，而 SessionValue 是第二个值。
我们应在 Session 中存放尽可能少的东西，这是由于如果对一个 Session 存值的话，这段代码势必也会对其他的 Session 存值。
再来看一下上面的那个 Session 结构，我们很容易能够发现，如果 Session 有很多的话，那个 HashMap 将会很大，再加之如果每一个 Session 中有大量值的话，将会导致那个 Hashtable 会很大很大，如果有很多用户执行那个往 Session 里存值的代码段时，由于此时的 Session 并没有过期，容器暂时不会把这个 Session 给销毁掉，这样的话会将服务器的 JVM 内存耗尽，特别是往 Session 中存入大量数据的 List 时。
为什么建议使用 Request 呢？这是由于 Request 的生命周期仅在一次请求和响应中，如果响应完成，当前的这个 Request 就会被销毁，JVM 的 GC 就有可能将其回收。
HttpSession 中一般只存放一些诸如用户名、验证码之类的数据。
我看到有很多人写的分页程序，把很多的查询条件，甚至查询结果都往 Session 里面塞，实际上这是一种极其不好的编程习惯，有点投机取巧，为了自己方便，而恣意地占用服务器宝贵的 JVM 内存。
草拟了两上 FAQ，希望能帮助楼主理解：
F：上面说到了验证码，为什么验证码能存在 Session 中呢？
Q：这是由于验证码需要做到一定程度上的保密，并且在验证完成后我们会主动销毁这个验证码，也就是说验证码的生命周期基本上在一个或多个请求/响应阶段。
F：我把那些查询条件，结果集在用户完成后也可以主动完成啊？
Q：我们可以设计这样一个场景：当用户点击查询后，我们在后台把所有的查询条件，以及两三页的结果集存放到 Session 中去了，然后返回给视图层，用户在看完第一页的数据后，可能会点下一页的数据，由于那些结果集在 Session 中已经存在了，我们后台或许直接在内存中就能完成这个分页操作，用户在看第二页时，会感到很快。这时用户不想看了，去点击其他页面了，这时我们服务器的 Servlet 容器当前连接的 Session 中还保存着那些数据，这些数据在用户关闭浏览器或者再回到这个页面查询前，都会成为服务器的垃圾而没有用处的东西。如果我们的应用的页面有很多都是这样操作的，那么我们的服务器 JVM 内存中的垃圾就会越来多，不幸的是，JVM 的 GC 并不认为这些是垃圾，GC 将会对这些数据视之而不理。直到用户关闭浏览器，销毁了 Session 后，JVM 的 GC 才会将这些垃圾回收掉。
http://topic.csdn.net/u/20100102/10/3580fea8-53af-4c6b-b410-e9a665eb8f3e.html
9 楼、11 楼
Session 在 Servlet 容器 Tomcat 中的存储结构是这样的：
HashMap<SessionId, Hashtable<SessionKey, SessionValue>>
其中
SessionId 是 Servlet 容器为当前 Session 分配的一个唯一值
SessionKey 是某 Session 中的 key 值，也就是使用 session.setAttribute 方法参数的第一个值，而 SessionValue 是第二个值。
我们应在 Session 中存放尽可能少的东西，这是由于如果对一个 Session 存值的话，这段代码势必也会对其他的 Session 存值。
再来看一下上面的那个 Session 结构，我们很容易能够发现，如果 Session 有很多的话，那个 HashMap 将会很大，再加之如果每一个 Session 中有大量值的话，将会导致那个 Hashtable 会很大很大，如果有很多用户执行那个往 Session 里存值的代码段时，由于此时的 Session 并没有过期，容器暂时不会把这个 Session 给销毁掉，这样的话会将服务器的 JVM 内存耗尽，特别是往 Session 中存入大量数据的 List 时。
为什么建议使用 Request 呢？这是由于 Request 的生命周期仅在一次请求和响应中，如果响应完成，当前的这个 Request 就会被销毁，JVM 的 GC 就有可能将其回收。
HttpSession 中一般只存放一些诸如用户名、验证码之类的数据。
我看到有很多人写的分页程序，把很多的查询条件，甚至查询结果都往 Session 里面塞，实际上这是一种极其不好的编程习惯，有点投机取巧，为了自己方便，而恣意地占用服务器宝贵的 JVM 内存。
草拟了两上 FAQ，希望能帮助楼主理解：
F：上面说到了验证码，为什么验证码能存在 Session 中呢？
Q：这是由于验证码需要做到一定程度上的保密，并且在验证完成后我们会主动销毁这个验证码，也就是说验证码的生命周期基本上在一个或多个请求/响应阶段。
F：我把那些查询条件，结果集在用户完成后也可以主动完成啊？
Q：我们可以设计这样一个场景：当用户点击查询后，我们在后台把所有的查询条件，以及两三页的结果集存放到 Session 中去了，然后返回给视图层，用户在看完第一页的数据后，可能会点下一页的数据，由于那些结果集在 Session 中已经存在了，我们后台或许直接在内存中就能完成这个分页操作，用户在看第二页时，会感到很快。这时用户不想看了，去点击其他页面了，这时我们服务器的 Servlet 容器当前连接的 Session 中还保存着那些数据，这些数据在用户关闭浏览器或者再回到这个页面查询前，都会成为服务器的垃圾而没有用处的东西。如果我们的应用的页面有很多都是这样操作的，那么我们的服务器 JVM 内存中的垃圾就会越来多，不幸的是，JVM 的 GC 并不认为这些是垃圾，GC 将会对这些数据视之而不理。直到用户关闭浏览器，销毁了 Session 后，JVM 的 GC 才会将这些垃圾回收掉。
加载更多回复（14）
