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. 

So
{quote}build highly responsive applications
{quote}
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
programming.
{quote}Can a poor man's implementation of this be built by bolting an asynchronous api on
top of JDBC?
{quote}
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.
{quote}
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.
{quote}
So do other databases, too, like SQL Server.
{quote}The network protocol (DRDA) appears to me to be synchronous.
{quote}
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
(v7.6.3#76005)

Mime
View raw message