那么什么是利弊呢？这个异步化可以提高app服务器的容量(即处理的并发请求)像nio吗？
解决方法
今天的大多数Web应用程序都是同步的,这得益于大多数Java(和Scala)Web框架的Servlet API.当我们现在看到support for asynchronous servlets时,这种支持并没有为所有框架做好准备.除非您从a framework that supports asynchronous processing开始,否则您的请求处理将是同步的.
对于JDBC,JDBC is synchronous.实际上,从来没有做过任何事情,考虑到修改世界各地的gazillion JDBC驱动程序实现的负担.我们可以希望,但不要呼吸.
并且JDBC实现本身不必是线程安全的,因此在完成同一连接上的某些其他操作之前在JDBC连接上调用操作将导致未定义的行为.和未定义的行为！=好.
所以我的猜测是,你看不到与NIO看到的完全相同的容量改进.
Edit: Just discovered 07004; an asynchronous database driver API. It’s an experimental project written for a master’s thesis,very early,experimental. It’s a worthy experiment,and I hope it succeeds. Check it out!
但是,如果您正在构建一个基于异步的基于actor的系统,我真的很喜欢拥有数据访问或存储库角色的想法,就像在分层OO架构中具有data acccess或repository对象一样.
演员确保消息一次一个处理,这对于访问单个JDBC连接是理想的. (一句话要小心：大多数连接池默认发出每个线程的连接,这与actor不能很好的相反,你需要确保你使用的是每个连接的连接,同样如此用于交易管理.)
这样就可以像数据库那样处理数据库,就像我们一直在对待的异步远程系统一样.这也意味着您的数据访问/存储库角色的结果为futures,即composable.这使得更容易将数据访问与其他异步活动进行协调.
那么好吗？可能,如果它符合您系统其余部分的架构.会改善能力吗？这将取决于你的整体系统,但这听起来像是一个非常有价值的实验.
