[
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)
