现在的DB内容本身价值极高，一些核心客户都是内部的一些部门，但是使用范围确实World Wide(WW)级别的，服务以Corba，EJB，web services形式发布，服务器配置是8CPU、32G内存，weblogic8.1SP5，每个Domain是Admin Server、Node Manager、Managed Server的拓扑结构，相关的使用的第三方组件也有EJB和Corba版本。
现在公司提供了一个Batch Process的流程，但是我觉得效果非常不好，10万条的记录以文本形式提交上来，这里面有几个问题：
1。没有使用NIO/JINI，效率不高。
2。每一条记录处理都要调用一次EJB（受限于第三方的组件，无法实现绕过EJB调用的处理方式）。
3。自己EJB需要调用第三方EJB，在thread hang住的情况不能主动提示。
4。Batch Process方面的用户权限和能够享受的服务不清楚。
我自己的几个考虑：
1。从观念上引入SLA， 把对应customer可以享受的服务和收费直接挂钩。里面技术相关参数可以类似以下几个等等：一次可以处理几个文件、一次可以处理多少记录、可以享受多少并发处理（比如，跟他说你给我XX钱，我就给你多少条线程同时处理你的请求）、我承诺你的有效响应时间是多少等等。
2。如果观念上行的通，接下来就是技术问题：
a). 对容器外线程的管理；
b). 对有可能比较耗费时间引起thread挂起的地方注册EJB TimerService，在Callback接口中丢出Timeout异常，封装现场信息，丢给Notification相关方，给用户friendly的出错提示或者尝试自动处理；
c). 用户提交的记录是否需要保存到DB，供后续查询和处理，以及做用户请求和服务level分析；
d). JMS实现上，增加自定义的selector，实现实时Debug信息功能供出现“挂起”现象时诊断（前面的故障排除是我用Thread Dump的方法来查看JVM中的内存Thread分布情况），同时保证日志信息的“事务完整性”；
e). 重构当前MDB，将处理逻辑移交MDB代码以外，增加新的DB Processor配合原有的log4j Processor，已备复杂后期处理使用；
f). 仔细考虑的一个问题是：现在的系统有很大一部分依赖与shell脚本和规则的文本文件，为什么不依赖数据库的唯一原因我想可能是项目组认为文本文件提供更好的可信度、可用度，也就是为了防止如果DB不可用的时候，服务还是不会中断，可以考虑一下如果DB为首选方案，文本为BackUp的解决办法的工作量和可行度，这个可能涉及到很多问题：信息同步、丢失数据及时导入等等，要根据业务逻辑找到一个合适的角度。
g). 另外，如果启动多少线程可以自由确定的话，直接影响我们另外一个EJB Pool的大小规划问题，同时还要考虑3个第三方产品之间的带宽限制，否则对用户的多线程的服务就是一个空话。
我想，如果可行的话，可以做一个方案出来，提交PM，主动从客户那里拉单子过来，客户还是比较有钱的，不过风险就是应用是WW级别的应用，如果一个处理不好，项目组就会粉身碎骨，所以还是需要跟PM做仔细仔细的分析。
PS. 目前在我计划内的是想跟客户提议实现对Weblogic（不是一个domain，而是WW级设计到的所有的Bea domain）的主动监控，而不是简单的ping自己的服务确定，这个在技术上不成问题。
