Slick 3.0在数据库驱动程序级别是反应/异步吗?对于哪些数据库?

Ed *_*aub 28 database asynchronous scala reactive-programming slick

Slick历来依赖于JDBC驱动程序,它在内部阻止等待套接字I/O以响应查询.每个未完成的数据库调用都需要一个线程来阻塞套接字; 因此,它与ReactiveMongo,postgresql-async和mysql-async在同一意义上并不是真正的反应,它们一直是异步的.

Slick 3.0在这方面有什么变化吗?或者我对此感到困惑?

cvo*_*ogt 27

它不是异步到驱动程序级别,但这不是问题.在良好的设置中,等待数据库连接的阻塞线程的数量应该很小.因此,他们不会消耗大量资源.Slick管理它们并调度阻塞线程到它们自己的线程池中,因此它们不会妨碍计算."本机"异步驱动程序可能会增加一个小的加速,但不是一个主要的加速.Slick可能在将来的某个时候支持它."反应"的主要好处来自Slick已经在3.0中实现的功能.可以在此处找到更广泛的解释:https://www.parleys.com/tutorial/reactive-slick-database-programming

  • 我明白你的观点,但我相信,在底层的[分析](https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing)中有一个大的星号,导致连接池的大小:_*假设硬件约束是数据库服务器上负载驱动延迟的唯一原因_.虽然在某些应用程序中可能会出现这种情况,但任何导致大量锁争用的问题(尤其是来自事务的锁争用)可能需要更多连接以避免池饱和引起的死锁.至少,这就是我的想法. (6认同)
  • 在这里添加了一张票,以检查有关浊音问题的反应灵活:https://github.com/slick/slick/issues/1131上述锁定争用和许多长期连接的具体示例(任何数字都可能是线程资源使用的问题)在这里会非常有用. (3认同)
  • 我决定[问一个更高的权威](https://github.com/brettwooldridge/HikariCP/issues/304)关于死锁问题. (2认同)