我正在构建一个传统的webapp，它通过JDBC进行数据库CRUD操作。我想知道在当前的请求处理线程中将jdbc操作放入actor是否合适。我做了一些搜索，但没有找到演示这个的教程或示例应用程序。
那么缺点和优点是什么？这个异步连接是否会像nio一样提高appserver的容量（即处理的并发请求）？
答案 0 :(得分：13)
将JDBC访问权限放在演员身上是否“好”或者不取决于应用程序的其余部分。
今天的大多数Web应用程序都是同步的，这要归功于大多数Java（和Scala）Web框架的基础Servlet API。虽然我们现在看到support for asynchronous servlets，但这种支持并没有在所有框架中发挥作用。除非您从a framework that supports asynchronous processing开始，否则您的请求处理将是同步的。
对于JDBC，JDBC is synchronous。实际上，考虑到修改世界上大量的JDBC驱动程序实现所带来的负担，我们永远不会做任何事情。我们可以希望，但不要屏住呼吸。
JDBC实现本身不必是线程安全的，因此在完成对同一连接的某些其他操作之前调用JDBC连接上的操作将导致未定义的行为。未定义的行为！=好。
所以我的猜测是你看不到与NIO相同的容量改进。
编辑 ：刚发现adbcj;异步数据库驱动程序API。这是一个为硕士论文写的实验项目，很早就是实验性的。这是一个有价值的实验，我希望它成功。看看吧！
但是，如果你正在构建一个基于actor的异步系统，我真的很喜欢拥有数据访问权限或存储库actor，这与你的data acccess非常相似或分层OO架构中的repository个对象。
Actors保证一次处理一个消息，这对于访问单个JDBC连接是理想的。 （需要注意的一点是：大多数连接池默认发布每线程连接，这对于演员来说效果不佳。相反，你需要确保使用每个演员连接。同样如此用于交易管理。）
这允许您将数据库视为我们应该一直对待它的异步远程系统。这也意味着您的数据访问/存储库角色的结果为futures，即composable。这样可以更轻松地将数据访问与其他异步活动进行协调。
那么，这样好吗？可能，如果它适合您系统其余部分的架构。它会提高容量吗？这取决于你的整体系统，但这听起来像是一个非常有价值的实验。