scala - 把jdbc操作放在actor里面好不好？

Question

我正在构建一个通过 JDBC 执行数据库 CRUD 操作的传统 web 应用程序。我想知道在当前请求处理线程之外将 jdbc 操作放入 actor 是否好。我做了一些搜索，但没有找到演示这个的教程或示例应用程序。

那么有什么优缺点呢？这种异步化会像 nio 一样提高应用服务器的容量(即处理的并发请求)吗？

Answer 1

将 JDBC 访问放在 actor 中是否“好”在很大程度上取决于应用程序的其余部分。

由于 Servlet API，当今大多数 Web 应用程序都是同步的它是大多数 Java(和 Scala)Web 框架的基础。虽然我们现在看到 support for asynchronous servlets ，这种支持并未在所有框架中发挥作用。除非你以 a framework that supports asynchronous processing 开头，您的请求处理将是同步的。

至于JDBC，JDBC is synchronous .考虑到修改世界上无数的 JDBC 驱动程序实现所带来的负担，实际上永远不会对此采取任何措施。我们可以抱有希望，但不要屏住呼吸。

并且 JDBC 实现本身不必是线程安全的，因此在同一连接上的某些其他操作完成之前调用 JDBC 连接上的操作将导致未定义的行为。和未定义的行为!= 好。

所以我的猜测是，您不会看到与 NIO 完全相同的容量改进。

Edit: Just discovered adbcj; 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 的系统，我真的很喜欢拥有数据访问或存储库actor 的想法，这与您拥有 data acccess 的方式非常相似。或 repository分层 OO 架构中的对象。

Actors 保证一次处理一条消息，这是访问单个 JDBC 连接的理想选择。 (一个警告:大多数连接池默认分配每个线程的连接，这对 Actor 来说效果不佳。相反，您需要确保您使用的是每个 Actor 的连接。同样如此用于事务管理。)

这允许您像对待异步远程系统一样对待数据库，我们应该一直对待它。这也意味着您的数据访问/存储库参与者的结果是 futures , 分别是 composable .这使得协调数据访问与其他异步事件变得更加容易。

所以 ， 好吗？可能，如果它适合您系统其余部分的架构。它会提高容量吗？这将取决于您的整体系统，但这听起来是一个非常值得的实验。