抱歉，言多必失，果然如此。
可惜这里不能做改动。老板把我上面的发言删了吧。
对老板我还是有敬意的，对所有敬业的人我都有敬意，无论他做什么行业。这一点远远要比某个具体观点重要。

你不要介意，生气的话谁都能说，谁都不服谁才有志气。

我当初生气是因为你提出多线程方案，我想不能误导别人啊，所以很生气，不过你后来言论也不再涉及多线程方案了，这样就好。

关于其他非 本主题讨论我另外开贴。

偶们的应用和MaJian很有相似之处，不过偶们调用的不是WebService，是CICS接口。偶们采用了同步的JMS消息队列做处理，在消息的接收端使用多线程去调用接口。 这个系统实际使用中也是问题多多，在服务提供方出现问题时，容易出现消息的积压，有时还会导致服务器宕机，解决办法应该有，但是偶8会。所以对Yin提的那个workmanager比较感兴趣中

>服务提供方出现问题时，容易出现消息的积压，有时还会导致服务器宕机
使用数据库作为你的JMS积压储存处，一般缺省是使用内存，当然会撑死服务器啊。

啊！我说多线程就是误导，因为你弄多线程不灵清。你说JMS就不是误导，看看人家YUXIE出来揭发JMS了吧？

搞 JMS 出问题的情况一点也不罕见。我就亲眼见过世界顶尖的商业应用开发商用了 JMS 之后很束手无策的。那个系统的架构师，两个人，一个是 ECLIPSE CHECKSTYLE 的作者，另一个是“Database Access Patterns”的作者（他本人还是IBM出身），下面还有资深开发好手，IBM技术顾问若干。如果这几位年轻有为的青年才俊都搞不定，那 JMS 的开发风险可想而知。骗别人弄这个东西，难道就不是误导？

何况我说了多线程有什么可能常见问题。如果多线程出了问题，你至少可以自己调试。要是花了钱买来 WEBSPHERE 又玩不转，岂不很郁闷？

我对 WEBSPHERE 的了解，至少 IBM 认证机构认为已经达到了最高水准，好歹也实践了好几年，从 WEBSPHERE 3.5 开练到今天的 6，也不敢随便给别人打 JMS 的包票。那个东西弄个“HELLO WORLD”是灵的，弄一百万个“HELLO WORLD”是要少几个 HELLO 的。老板要是没怎么弄过 JMS，那你可真的是误导啊。

To Yuxie:

如果你用 WEBSPHERE，那么它已经有 WORKMANAGER 的支持了。如果你用WEBLOGIC，需要用WEBLOGIC 9。不过如果我来做选择，我可能仍然会首选多线程，同时做个WORKMANAGER的原型测试，因为多线程是一个成熟技术。一个你认识的怪物，要比你不认识的怪物容易对付。

JMS 本来不是设计用来做这种用途的，我认为。呵呵～～ 这种场景用JMS，好像杀鸡用加农炮了，打不打得着鸡不说，弄不好还震坏自己的耳朵～～ 其实理想状态下，JMS 不该这么复杂的。可惜现实情况不是这样。但是你的消息积压问题, 个人感觉应该是应用系统设计本征问题，而不是配置问题。是不是应该调整一下消息交换的方式，比如“请求－确认－响应”，这样至少可以避免消息积压。

用数据库做消息缓存，大概也有效，但是有点治标不治本的意思。

别再在这里嘴硬了，人家楼主还没发话，你急什么急啊，我给你骂的那样都没你这么急呢。
你不认为误导就可以，用心是好的，手段可能造成误导，这是正常，我也经常范这个毛病。

让我们Jdon的帖子显得专业一点好不好，不要再灌水啦!

To Yuxie:

我想我大概没有解释清楚所谓“请求－确认－响应”的意思：

关于消息积压问题，我猜测你的消息消费方是支持事务的，所以当后台系统访问的问题最终导致了事务 ROLL-BACK，从而导致已交付消息被session自动恢复并试图重新交付最终形成积压。

还有一个可能是你的消息确认是手动的（CLIENT_ACKNOWLEDGE），但是由于后台处理失败因而没有进行消息确认。

如果是上述两种情况之一，可行的办法是修改消息消费者的逻辑，即使后台系统访问失败也仍然提交事务，或者手工确认（message.acknowlege()），然后再结果响应数据中（我不知道你的结果响应使用什么手段）表明访问失败。

另外一个办法是再发送消息的时候指定 time-to-live，至少给JMS PROVIDER一个机会把消息扔掉。

非常感谢！……我这里过期时间是有指定的，持久化策略为不持久化，消息过期策略为删除，没有使用事务……偶以为这个东东根本8需要jms~算了，不去管它了，这一阵子倒是稳定的很~天天加班忙别的了~

各位不要吵拉，这种争论还是没有结果阿。非常感谢各位的指导，小弟目前仍采用了Struts + Spring和concurrent多线程包的处理办法，其中只是使用了Spring的事务管理。经过初步的并发模拟测试，通过线程池方式来控制异步访问相当稳定，并且基本达到预期设想的效果。当然这还是在测试阶段，离实际运行的并发量相比较还是有差距。下个月项目就要上线，之前会做一个压力测试，相信会给大家一个实际的答案的。

谢谢Kyle_Yin提供的各种实现方案，对我帮助很大，真心感谢。

多线程肯定能解决问题，其实我们现在的所有所谓J2EE应用，只要多线程加数据库就可以全部实现。

可是软件的可扩展性 可维护性 可拓展性和可伸缩性到哪里去了呢？

用了多线程就没有了维护性？可扩展性？可伸缩能力？

不明白耶。

通用的框架解决的是通用的问题，但不一定是最佳的解决方案。

做技术也是追求真理的一种方式，不必做某种技术的保皇派吧。

我相信技术方案只有最适合的，没有所谓最好的和最通用的。

没有针对Majian你这个案例，有可能特殊，项目紧。

我们都认可维护性？可扩展性？可伸缩能力就可以，至于什么方式达到，可以慢慢研究总会达到。

上页
下页