将jdbc操作放在actor中好吗?

对于JDBC， JDBC是同步的.实际上，考虑到修改世界上千篇一律的JDBC驱动程序实现所带来的负担，对此永远不会做任何事情.我们可以希望，但不要屏住呼吸.并且JDBC实现本身不一定必须是线程安全的，因此在对同一连接执行某些其他操作之前调用JDBC连接上的操作将导致未定义的行为.还有未定义的行为！=好.所以我的猜测是，您不会看到与NIO完全相同的容量改进. 编辑 :刚刚发现 adbcj ;异步数据库驱动程序API.这是一个为硕士论文编写的实验性项目，很早就具有实验性.这是一个值得的实验，我希望它能成功.看看吧！ 但是，如果您要构建一个基于参与者的异步系统，我真的很喜欢拥有数据访问权限或存储库参与者的想法，就像您拥有数据访问或存储库对象位于分层OO体系结构中. Actor保证一次处理一条消息，这是访问单个JDBC连接的理想选择. (请注意:大多数连接池默认都分发每个线程的连接，这在actor上不能很好地发挥作用.相反，您需要确保使用的是每个actor的连接.这是正确的用于交易管理.)这使您可以像对待异步远程系统一样对待数据库，我们应该一直将其视为一直.这也意味着您的数据访问/存储参与者的结果是未来，它们是可组合.这样可以更轻松地将数据访问与其他异步活动进行协调. 那么，好吗?可能的话，如果它适合您系统其余部分的体系结构.会提高容量吗?这将取决于您的整个系统，但这听起来像是一个非常值得的实验.I am building a traditional webapp that do database CRUD operations through JDBC. And I am wondering if it is good to put jdbc operations into actors, out of current request processing thread. I did some search but found no tutorials or sample applications that demo this. So What are the cons and pros? Will this asynchonization improve the capacity of the appserver(i.e. the concurrent request processed) like nio? 解决方案 Whether putting JDBC access in actors is 'good' or not greatly depends upon the rest of your application.Most web applications today are synchronous, thanks to the Servlet API that underlies most Java (and Scala) web frameworks. While we're now seeing support for asynchronous servlets, that support hasn't worked its way up all frameworks. Unless you start with a framework that supports asynchronous processing, your request processing will be synchronous.As for JDBC, JDBC is synchronous. Realistically there's never going to be anything done about that, given the burden that would place on modifying the gazillion JDBC driver implementations that are out in the world. We can hope, but don't hold your breath.And the JDBC implementations themselves don't have to be thread safe, so invoking an operation on a JDBC connection prior to the completion of some other operation on that same connection will result in undefined behavior. And undefined behavior != good.So my guess is that you won't see quite the same capacity improvements that you see with 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!But, if you are building an asynchronous, actor-based system, I really like the idea of having data access or repository actors, much in the same way your would have data acccess or repository objects in a layered OO architecture.Actors guarantee that messages are processed one at a time, which is ideal for accessing a single JDBC connection. (One word of caution: most connection pools default to handing out connection-per-thread, which does not play well with actors. Instead you'll need to make sure that you are using a connection-per-actor. The same is true for transaction management.)This allows you to treat the database like the asynchronous remote system we ought to have been treating it as all along. This also means that results from your data access/repository actors are futures, which are composable. This makes it easier to coordinate data access with other asynchronous activities.So, is it good? Probably, if it fits within the architecture of the rest of your system. Will it improve capacity? That will depend on your overall system, but it sounds like a very worthy experiment. 这篇关于将jdbc操作放在actor中好吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！