29

Slick has historically relied on JDBC drivers, which internally block waiting for socket I/O in response to queries. Every outstanding database call requires a thread to block on a socket; hence, it's not really reactive in the same sense as ReactiveMongo, postgresql-async and mysql-async, which are asynchronous all the way down.

Has anything changed in this regard in Slick 3.0? Or am I confused about any of this?

Ed Staub
  • 15,480
  • 3
  • 61
  • 91
  • 1
    Auctally slick 3.x has very poor transaction performance. I've made a micro benchmark [here](http://jilen.github.io/sdb/). – jilen Jan 26 '16 at 09:34

1 Answers1

29

It is not async down to the driver level, but that is not a problem. The number of blocking threads waiting for database connections is supposed to be small in a good setup. Thus they don't consume a lot of resources. Slick manages them and schedules blocking threads into their own thread pool, so they aren't in the way of computations. A "native" async driver would probably add a minor speedup, but not a major one. Slick may support that at some point in the future. The major benefit of "reactive" comes from what Slick already implements in 3.0. A more extensive explanation can be found here: https://www.parleys.com/tutorial/reactive-slick-database-programming

cvogt
  • 11,260
  • 30
  • 46
  • 6
    I see your point, but there's a big asterisk missing, I believe, in the underlying [analysis](https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing) that leads to a small connection pool size: _* assuming that hardware constraints are the only cause of load-driven latency on the database server_. While this may be true in some applications, any that incur a significant amount of lock contention, especially from transactions, may need many more connections to avoid pool-saturation-induced deadlock. At least, that's what I think. – Ed Staub Apr 13 '15 at 05:34
  • 2
    I decided to [ask a higher authority](https://github.com/brettwooldridge/HikariCP/issues/304) about the deadlock concern. – Ed Staub Apr 13 '15 at 05:52
  • 3
    Added a ticket here to review reactive slick with regards to the voiced concerns: https://github.com/slick/slick/issues/1131 Concrete examples for the mentioned lock contention and many long standing connection (in any number that would be a problem for thread resource usage) would be very helpful here. – cvogt Apr 14 '15 at 15:23
  • 1
    youtube version of reactive-slick-database-programming if you don't want to sign up to parleys https://www.youtube.com/watch?v=WvxXz7aklik – Mullefa May 11 '16 at 08:31