将 JDBC 访问放入 actor 中是否“好”很大程度上取决于应用程序的其余部分。
如今大多数 Web 应用程序都是同步的,这要归功于服务程序接口 http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServlet.html它是大多数 Java(和 Scala)Web 框架的基础。虽然我们现在看到支持异步 Servlet http://wiki.eclipse.org/Jetty/Feature/Continuations,这种支持并没有在所有框架上发挥作用。除非你开始于支持异步处理的框架 https://github.com/spray/spray/wiki,您的请求处理将是同步的。
至于 JDBC,JDBC 是同步的 https://stackoverflow.com/q/4087696/115478。实际上,考虑到修改世界上无数的 JDBC 驱动程序实现所带来的负担,永远不会对此采取任何措施。我们可以抱有希望,但不要屏住呼吸。
而且 JDBC 实现本身不必是线程安全的,因此在同一连接上完成某些其他操作之前调用 JDBC 连接上的操作将导致未定义的行为。未定义的行为!=好。
所以我的猜测是,您不会看到与 NIO 完全相同的容量改进。
Edit: 刚刚发现adbcj http://code.google.com/p/adbcj/;异步数据库驱动程序 API。这是一个为硕士论文写的实验项目,很早,实验性的。这是一个值得尝试的尝试,我希望它能成功。一探究竟!
But,如果您正在构建一个异步的、基于参与者的系统,我真的很喜欢拥有数据访问或存储库参与者的想法,就像您拥有的方式一样数据访问 http://static.springsource.org/spring/docs/3.0.x/reference/html/jdbc.html or 存储库 http://debasishg.blogspot.com/2007/02/domain-driven-design-inject.html分层 OO 架构中的对象。
Actor 保证一次处理一条消息,这对于访问单个 JDBC 连接来说是理想的选择。 (需要注意的是:大多数连接池默认分配每个线程的连接,这对于参与者来说效果不佳。相反,您需要确保使用的是每个参与者的连接。同样如此用于事务管理。)
这使您可以像对待异步远程系统一样对待数据库,而我们应该一直将其视为异步远程系统。这也意味着您的数据访问/存储库参与者的结果是futures http://doc.akka.io/docs/akka/current/scala/futures.html, 哪个是可组合的 http://doc.akka.io/docs/akka/current/scala/futures.html#Composing_Futures。这使得协调数据访问与其他异步活动变得更加容易。
So, 好吗?可能是这样,如果它适合系统其余部分的架构。会提高能力吗?这将取决于您的整个系统,但这听起来是一个非常值得的实验。