Are the JDBC drivers (as described on https://www.playframework.com/documentation/2.2.x/ScalaDatabase ) blocking or non-blocking?
If they’re blocking… how does that fit into the rest of Play methods being non-blocking?
1 Like
The drivers are blocking, there’s an initiative in the more general java community to define a non-blocking jdbc standard alternative.
Play, and any other scala library building on top of jdbc, commonly uses a dedicated thread-pool to isolate the blocking code and present an asynchronous API.
Related: for postgres, there’s an ongoing effort to write a totally non-blocking functional scala library for db operations, named skunk
I guess one of the most promising efforts to define a standard API for non-blocking database access for Java right now is https://r2dbc.io. I recently attended an interesting talk from one of the creators. If you are interested here are the slides: https://speakerdeck.com/mp911de/reactive-relational-database-connectivity and a recording of a previous talk: https://www.youtube.com/watch?v=yU3Hf2krxF4 (if you speak german: https://www.youtube.com/watch?v=sUXKDGt3QRk).
1 Like
So, in the case of websockets code, where I’m processing stuff thru websockets and writing stuff to db at the same time - what would be the recommended way to have the writes done asynchronously without blocking the communication over WS?
If you rely on Slick’s integration for Play, e.g., the database connection operations would be done using a preconfigured (hikari-db) connection pool dedicated to Slick, that is configured directly in the application conf.
Otherwise you want to define a dedicated execution context on a bounded pool, and send all blocking operations to that context.