拟用EJB3实现一个大型在线支付系统

正在考虑采用EJB3来构建一个大型的在线支付交易系统。特点是无前端界面，只提供服务接口；每日交易量巨大，对TPS（每秒处理的交易数）的指标要求较高。由此带来的技术性要求为：
1. 对大并发的访问压力有足够承受能力；
2. 响应时间必须足够短（3秒以内）；
3. 具有企业级的事务完整要求；
4. 企业级的安全性；
5. 方便实时监控系统运行状态参数，如访问量曲线等；
6. 与银行系统的可靠连接。
采用EJB3，主要是希望利用容器的强大和成熟性，避免重复编写企业级的环境类代码，而将主要精力放在业务实现上。EJB3为本项目至少可以带来对象池的管理、声明式事务支持、透明的集群机制、及其相当程度的安全性。EJB分布式的优点暂时还用不上，准备仅仅使用本地接口的方式，从接入门户系统直接调用。EJB持久层用EJB3.0的JPA。接入系统采用的技术还未深入思考，大致有两种思路：Servlet容器或者自己编写基于javax.concurrent的线程池。
当然，用EJB最担心的还是性能问题，不知道Spring这样的轻量级框架对于这个项目是否就够用了。希望可以通过与大家的讨论，做一次成功的选型。

>每日交易量巨大

到底有多大？ 每天最大量是多少？ 每秒最大量是多少？

EJB3刚出来，哪有成熟性可言
建议楼主把《without ejb》仔细看一遍，尤其是关于对象池、集群和持久化的讨论

这东西应该是对DB的要求高吧!

用了分布式就别说自己要求有多高多高的性能了，关于如何正确使用ejb，我想without ejb中并没有写，但是在他的前面一本书里写了，大意就是不要用有状态的，和远程的session bean， 也就是说用slsb是没有问题的，可惜我们公司现在就是背道而驰啊。如果楼主用ejb3.0的话，起码要有那种对ejb2.0或2.1比较有经验的人，如果没有的话不要轻易冒险

为什么怀疑EJB存在性能问题呢？
那你觉得Entity Bean，EJB集群是用来干什么的？

如果你觉得在低端配置的机器，或者单台机器上的性能不如轻量级框架，那还可以理解。

ejb3无疑是大型应用的首选！

如果楼主认为项目的会有大量的业务逻辑，无疑不能选spring,使用spring的话会将事务限制在spring的API里，那样J2ee变成了一张废纸！

ejb如果用得不好确实可能会产生性能问题，特别是如果大量使用remote和stateful得session bean的时候，这个问题是早有定论的，还有集群和分布不是同一回事，说集群，那想spring这种轻量级框架也是可以集群的，罗德约翰生建议即使使用ejb，也要用slsb，这个我想大家应该没有异议的吧，我们公司现在的做法是既集群又分布，呵呵，大量使用remote session bean，在开发的时候我就已经觉得很慢了，但是他们说要通过集群来把性能提上去，成功与否还不知道，我觉得现在我们拐了个弯，代价是更多的硬件，更长的开发时间，性能未必高到哪里去

我也有这样的感觉,EJB3不是为中小型应用准备的东西.有空一定要好好学学,领会EJB3的剑道.