Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What are the options to use JDBC in a non-blocking way in Play?

I wonder what is the best (recommended, approved etc.) way to do non-blocking JDBC queries in Play! application using Play's connection pool (in Scala and to PostgreSQL if it matters)? I understand that JDBC is definitely blocking per se, but surely there are approaches to do the calls in separated threads (e.g. using futures or actors) to avoid blocking of the calling thread.

Suppose I decided to wrap the calls in futures, which execution context should I use, the Play's default one? Or it's better to create separated execution context for handling DB queries?

I know that there are some libraries for this like postgresql-async, but I really want to understand the mechanics :)

like image 529
Ivan Yurchenko Avatar asked Oct 03 '14 10:10

Ivan Yurchenko


People also ask

What are blockings in JDBC?

You can use a blocked insert operation to insert several rows into a database table at a time. A blocked insert is a special type of operation on IBM® i that provides a highly optimized way to insert several rows into a database table at a time.

What is it that we use for JDBC connection pooling in our applications?

JDBC 3.0 API Framework. The JDBC 3.0 API provides a general framework with "hooks" to support connection pooling rather than specifying a particular connection pooling implementation. In this way, third-party vendors or users can implement the specific caching or pooling algorithms that best fit their needs.

Why should JDBC connection be closed?

At the end of your JDBC program, it is required explicitly to close all the connections to the database to end each database session. However, if you forget, Java's garbage collector will close the connection when it cleans up stale objects.

Is JDBC synchronous?

While it's not possible to have a true synchronous JDBC adapter, it is possible to combine a Sender and Receiver channel in order to get a similar result.


1 Answers

Suppose I decided to wrap the calls in futures, which execution context should I use, the Play's default one? Or it's better to create separated execution context for handling DB queries?

It is better to use separate execution context in this case. This way there will be no chance that your non-blocking jobs (most of the default Play's stuff) submitted to default execution context will be jammed by blocking JDBC calls in jobs you submit to the same execution context.

I suggest to read this (especially second part) to get a general idea of how you could deal with execution contexts in different situations (including case with blocking database queries), and then refer this to get more details on configuring your scenario in Play.

like image 130
Eugene Loy Avatar answered Sep 23 '22 14:09

Eugene Loy