最后的探讨
这儿描述的这种方案因为简洁的原因写得相当简单，有一些地方明显值得改善。
前瞻性的访问量分析和动态批处理
在这里我们设置mIntervalTime的值为50毫秒。假设访问量很小，平均100毫秒才有一个新的请求，那么我们将会延迟每个请求将近 25毫秒。我们如何才能以免这种低访问量惩罚呢?解决方案来自基于前瞻性访问量分析的动态批处理。换句话说，我们根据前一次会话中的用户请求数来可以改变批处理中的最工作数据。最简单的算法如下:
1、 记下最近50毫秒内服务的请求数量。
2、 如果数据小于5，则设置mJobBatchMaxSize为1否则为5。
如我上面讨论的，当mJobBatchMaxSize为1时，TrainServlet就与ClassicServle一样了。
多个命令的分配器
标准WEB应用服务器处理多个命令而不是一个，实际应用中Dispatcher和Worker应该能为所有的服务。每一个命令应该有自己的Worker类，Dispatcher应该作为一个单例来实现。然而，这儿两种可能的Dispatcher设计方式:
1、每一个命令有一个自己的Dispatcher类。如果特定时间后，没有请求需要服务则Dispatcher线程就退出，因为我们不需要很多空闭的线程来消耗系统资源。因此对比在serverlet的init()方法中实例化Dispatcher，我们更倾向于调用: Dispatcher.getIntance().AddJob(job)。
2、 仅有一个类来管理来自不同命令的不同批处理并且通过命令名将他们与相关的工作者相关联。这时候，调用看起来更像:Dispatcher.getInstance().AddJob(this.getClass().getName(),job).
作为JDBC代理的Train模式
从实际的观点来看，想从运行中的标准应用或者放弃传统的想法来重新构建应用是困难的。那么如果构建某种JDBC代理使得来自应用的JDBC调用基本一致时会怎么样呢?可以用EJB作为包装器来处理。这种方式是有效的，因为他可以处理任何如并发用户访问网络资源或数据库的应用而不只是服务于WEB 应用。但是这已经是另一个主题了。
小结
在这篇文章中，我们设计了一种新的称为Train的方式来开发有效的WEB应用。我们基于Train模式构建了一个实际的应用并且证明他可以在压力测试提供100%的性能改善。Train模式的使用并不限于WEB应用，通过减少软硬件的需求，他可以为任何处理并发用户访问网络资源或数据库的应用带来好处。
在这里特别感谢我的朋友们Mark Jackson, Sander Berents, Tom Griffin, and Eric Van Stegeren对我的支持和帮助。
