db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Paluch (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-7036) Investigate an R2DBC client implementation
Date Mon, 25 Feb 2019 07:50:00 GMT

    [ https://issues.apache.org/jira/browse/DERBY-7036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16776595#comment-16776595

Mark Paluch commented on DERBY-7036:

The problems that reactive programming solves are the shortcomings of the imperative programming
model. These are waiting for I/O wait (blocking I/O) and thread occupation longer than necessary,
in particular. 

{quote}build highly responsive applications
nails it.

We preserve the semantics of consistency and correctness. The two things that change is that
applications work with a small reasonable (often fixed) number of threads and they use non-blocking
code to perform a piece of work and as soon as this is done, the underlying thread processes
another chunk of work. All I/O is non-blocking and as soon as a response is sent, the thread
can continue its work. As soon as inbound response data arrives, a thread picks up work from
there and processes a response. Therefore, this is typically called event-driven, functional-reactive
{quote}Can a poor man's implementation of this be built by bolting an asynchronous api on
top of JDBC?
Yes, you can and this is being done for applications that want to use reactive APIs and do
not have high scalability requirements, see:
 * [https://github.com/davidmoten/rxjava2-jdbc]
 * [https://github.com/oracle/oracle-db-examples/tree/master/java/AoJ]

{quote}Re-plumbing Derby to operate truly asynchronously would be a big project.
I would be surprised to hear otherwise. This shouldn't be the goal here.
{quote}The engine assumes that only one statement at a time can run inside a session/connection/transaction.
So do other databases, too, like SQL Server.
{quote}The network protocol (DRDA) appears to me to be synchronous.
This reads for me as request/response without pipelining.

Regarding your last sentence, let me pick up on asynchronicity/concurrency. This is something
that comes up often when speaking about reactive usage. Reactive does not impose async/concurrency
behavior on any given source. In fact, most sources (speaking of a single connection) can
do only one thing at a time and that is perfectly valid.

What we want to achieve is, that while sources are busy with preparing/producing responses,
that we want to use CPU time on the application efficiently. While a source of data is busy,
we switch execution to a unit of work that is ready to be processed.

R2DBC drivers for Postgres and SQL Server have a strong connection-affinity. A connection
cannot process two queries in parallel nor can it handle two concurrent transactions. The
rules of the underlying database apply to a connection and this is how it is supposed to work.
We use the advantage of a non-blocking I/O layer to interact with the database according to
its protocol rules.

> Investigate an R2DBC client implementation
> ------------------------------------------
>                 Key: DERBY-7036
>                 URL: https://issues.apache.org/jira/browse/DERBY-7036
>             Project: Derby
>          Issue Type: Improvement
>          Components: Network Client
>            Reporter: Mark Paluch
>            Priority: Major
> As programming models evolve towards functional data access patterns, it would be great
to have a non-blocking, reactive network client implementation for Derby. The advantage of
having a non-blocking I/O layer allows to scale applications by orders of magnitude.
> There's an effort named R2DBC to bring Java-based, reactive database access to relational
databases using a standardized API. This ticket is here to start some discussion around whether
you'd be interested to look into this and how we can help.
> A few resources to get you started:
>  * The project organization can be found [on Github|https://github.com/r2dbc] and contains
the SPI, a client API as well as Postgres implementation and an H2 implementation.
>  * An [in-depth talk on the topic|https://www.youtube.com/watch?v=idApf9DMdfk] by Ben
Hale which is basically _the_ introduction you can get.
>  * There's a [public mailing list|https://groups.google.com/forum/#!forum/r2dbc] that
summarizes the events and activities around R2DBC.
>  * There's the [Spring Data R2DBC project|https://github.com/spring-projects/spring-data-r2dbc]
that provides a good overview of how functional-reactive data access can look like.

This message was sent by Atlassian JIRA

View raw message