数据存放（Session or request），希望能找到平衡点！

非常感谢，以后自己做项目的时候一定要注意。多使用cache之类的技术来减少DB的负担。

如果只是查询的话，每次只取1页显示的数据；如果包含大量计算的话，先把数据抽取到临时表，然后再取1页显示数据。
导出全部数据单做。
session中是绝对不能放这么多数据的，会把应用服务器拖死。

如果用olap解决，数据量太大也是个问题。（当然如果维度小的话是可以）。
我前面接手过一个东西，由于前期设计太差，每个分析维的维成员都大得不成样子，一个CUbe中分析维还多得不得了。所以最后根本很难跑动。现在我又从那个项目组撤离了，交给另外一同事维护。他现在正挣扎在深渊中。

所以没有好得设计，什么技术手段也解决不了。

顺便说下：
不是什么东西都能上升到OLAP来解决得。 向你这种，应该是通过 ETL 解决。

不知道这里的大鸟们是不是都是一门心思都钻Java去了，以为J2EE是万能得。实际上，楼主刚面临问题得时候，想到的就应该是做ETL解决。像这种，根本不应该是在APP server解决的。当然，在这个问题中，引申出那么多session 的讨论对大家学习还是很有益的。

真搞笑,把全部數據放在session裏,妳以為session是垃圾桶啊,沒錯,可以當垃圾桶,不過這樣的話,這垃圾桶也真大hoo,還有一點,妳的客戶會為暸一個小項目而去買一個10G內存 100GCPU 1000Gbps的網絡不?
至少我還是覺得每次錯暸就囬數據庫撈囬來,這樣不錯,數據庫有事務處理

好像还一定要在相同的域名下面？

基于Cookie的SSO方案是一定要在同一个域下。还有其他的方案，google之。

我是采用的是静态变量,不知合理吗

web服务器-----(中间有防火墙,只开80端口,走soap)---->应用服务器
------(中间双有防火墙,只开80端口,走soap)---->接口机(接口机有多台,每一台基本上有一种服务是专门用来到子系统里取相关数据.)
这里共有三层,每一个层都有几台机子做weblogic集群.
应用服务器还链接有数据库服务器集群.

我目前只是把从接口机里取的数据放在web层的staitc变量里,退出时再去清除.
因为用户通过web层取数据开销太大的.我只能在web层的某个JSP页面当用户有点击时才刷新去取接口层的数据.

目前我们也不采用session.基本上用全局变量才保存公共数据.包括登陆信息也不用session.
我现在头痛的是不知接口取过来的数据放在哪里暂时存入比较好.最主要的是怎样比较安全,各位有什么好方法没有.

就servlet规范本身，数据可以放在3个地方：request、session、servletContext.

request：
好处：用完就仍，不会导致资源占用的无限增长。
弊处：每次要用都从数据库中抓，多做操作，自然会对性能有一些影响。

session：
好处：不用每次都去数据库抓，少做操作。
弊处：每个客户都有一个session，只能自己使用，不同session可能保存大量重复数据；
      可能耗费大量服务器内存；
      另外session构建在cookie和url重写的基础上，所以用session实现会话跟踪，会用掉一点点服务器带宽和客户端保持联络，
      当然session越多，耗费的带宽越多，理论上也会对性能造成影响。
      集群的session同步会是个问题。

servletContext：
好处：不用每次都去数据库抓，少做操作。
      存储的数据所有客户都可以用。
      可减少重复在内存中存储数据造成的开销。
弊处：很多时候相同的数据可能不多(相当于cache的命中率很低）。


其实以上3中方法都有利有弊，各自的好处在某种条件下，也都会转变为弊处。所以不妨综合使用，相当于一个“第三方用法”（只讲一下思路，否则太过繁琐，涉及到的相关技术点请参考有关技术资料）：

request不说了，重点说说session和servletContext：

--session的可控应用
session的最大问题是资源回收，两类回收方法:
主动回收：浏览器被关闭，而为提交触发清理动作的请求时，该方法失效，而且很常见。
超时回收：设置session的setMaxInactiveInterval属性或在web.xml中配置超时时间，然后交给jvm的垃圾处理器处理。
          不过不要报太大希望，jvm的垃圾收集器并不灵光。
可以用另一种替代方法缓解该问题，比如限制session的数量，可以用HttpSessionListener实现，这样可以缓解session带来的吃内存问题，当然这种做法每次都需要判断session数量，当session达到限定数量时还必须用其他方法处理了，这些细节繁琐，而且要谨慎处理。

--servletContext
如果说session是一个“局部缓存”，那servletContext就是一个“全局缓存”了，不妨把它当作cache（这里不讲究用词的严谨性，仅为了更好说明问题）。cache的大小是当前应用可使用的最大内存。cache的最大问题是提高命中率，命中率高，内存占用少，效率高，命中率低，则内存占用多而且效率低。这种应用的技术实现比“session的可空应用”要简单，适用于相同数据多的地方，这个要事先有所判断，如果用不好则有弊无利。

如果仅使用servlet规范给出的3种机制，任何一种都达不到好处兼收的效果，所以要发挥3种方法的好处、摒弃弊处，必须综合运用，做一些技术框架的构建工作，而且有些地方还比较繁琐（还好框架是可重用的）。

有时候寻求或实现“平衡”（或者说尽取其利而摒其害），要付出很大代价，根据不同的情况，这些代价或是值得，或是不值得。也可以“两害相权取其轻”，或许是最便捷的方法。