features/sql: read result sets with plain JDBC instead of rxjava3-jdbc

[cportele]

Closes the last variant of the connection leak behind ldproxy/ldproxy#1761 — on the read path this
time — and, with no user left, removes the rxjava3-jdbc dependency. This goes beyond
ldproxy/ldproxy#1645, whose "remove usage of rxjava3-jdbc" concerns the SQL mutations and is
covered by #624.

Problem

Streamed reads — a positive fetch size, as used by single-shot queries — ran in a rxjava3-jdbc
transacted select, which commits and releases the connection only once the rows are exhausted.
An error while reading, or a cancellation (the read-stall timeout from #606, a client that went
away), left the connection leased for good.

Change

All reads lease a connection from the pool and stream the result set with Flowable.using +
Flowable.generate; statement, result set and connection are released on completion, error and
cancellation alike. A read with a fetch size still runs in a transaction so the driver uses a
server-side cursor (ended with a rollback, the cheapest way to close the cursor). Everything
reactive is unchanged: backpressure, execution on the subscribing thread, subscribeOn for
parallel single-shot sub-queries, the read-stall timeout, the SQL result logging.

Differences to the library's Select: errors raised while rows are streamed now reach the consumer
(the library swallowed them, which is what the transacted read was working around), resources are
released before completion is signalled downstream, and query strings are no longer scanned for
?/:name placeholders (ldproxy never binds parameters).

With no user left, the rxjava3-jdbc dependency, the Database in SqlConnectorRx and the unused
SqlDbmsAdapter.getRxType() are removed.

Why the library is not missed

rxjava3-jdbc is a general-purpose reactive JDBC wrapper; ldproxy used a narrow slice of it, and
that slice is exactly what the ~60 lines in SqlClientRx now do directly. Feature by feature:

rxjava3-jdbc capability	use in ldproxy	after this PR
Non-blocking connection pool (Pools.nonBlocking())	never used — the Database was created with fromBlocking(hikariDataSource), so every read ran synchronously on the subscribing thread	unchanged: lease, execute and read run on the subscribing thread; subscribeOn where parallelism is wanted
Parameter binding (?, :name, collection expansion, statement reuse across parameter groups)	never used — every statement arrives as a fully rendered string; the library still parsed each one for placeholders	not needed; no parsing of the SQL text (a latent hazard with a literal ?, e.g. the JSONB ? operator, is gone)
Row mapping (auto-mapping to interfaces/tuples, ResultSetMapper)	not used beyond passing our own SqlRowVals.read(ResultSet, options)	same mapper called directly
Transactions (transacted(), Tx, dependsOn, returnGeneratedKeys)	the write path (removed in PR 1); for reads only to obtain a server-side cursor	setAutoCommit(false) + setFetchSize do that in two lines
Batching, stored procedures (Call), pool health-check queries (DatabaseType)	never used (getRxType() had no caller)	removed
Query timeout	passed as 0 (none)	none (the read-stall timeout covers the stall case)
Resource lifecycle	Flowable.using(prepare, generate over rs.next(), close) — the same structure as the new code — but with the transacted variant's reference counting on top, which releases only on natural completion	Flowable.using + Flowable.generate without the counter: release on completion, error and cancel

So the library provided no capability the read path used that plain JDBC under RxJava does not
provide equally; what it added on top was the reference-counted transaction handling that caused
the leak, an SQL placeholder parser we did not need, the swallowed streaming error (#1293), and a
fork (0.1.4-ii.1) to maintain. The reactive contract of the read path — a backpressured
Flowable<SqlRow>, one connection per subscription, cancellation from downstream — is provided by
RxJava itself and is unchanged.

Verification

• SqlClientRxSpec: streamed and paged reads release statement, result set and connection on
  completion, on cancellation, on a failing next(), on a failing execute and on a failed lease;
  run() and session paths.
• End to end: ordinary reads (items with counts, paging, bbox, single feature, HTML, extents)
  unchanged; six large reads aborted by a throttled client mid-stream returned their connection
  every time (pool at baseline, HikariCP total equal to the database's backend count); the
  search/result-set and stored-query smoke tests — which include a header-only read of a
  100k-feature stored query, i.e. a cancelled streamed read — and the transaction smoke tests pass.

[cportele]

Closes the last variant of the connection leak behind ldproxy/ldproxy#1761 — on the read path this
time — and, with no user left, removes the rxjava3-jdbc dependency. This goes beyond
ldproxy/ldproxy#1645, whose "remove usage of rxjava3-jdbc" concerns the SQL mutations and is
covered by #624.

Problem

Streamed reads — a positive fetch size, as used by single-shot queries — ran in a rxjava3-jdbc
transacted select, which commits and releases the connection only once the rows are exhausted.
An error while reading, or a cancellation (the read-stall timeout from #606, a client that went
away), left the connection leased for good.

Change

All reads lease a connection from the pool and stream the result set with Flowable.using +
Flowable.generate; statement, result set and connection are released on completion, error and
cancellation alike. A read with a fetch size still runs in a transaction so the driver uses a
server-side cursor (ended with a rollback, the cheapest way to close the cursor). Everything
reactive is unchanged: backpressure, execution on the subscribing thread, subscribeOn for
parallel single-shot sub-queries, the read-stall timeout, the SQL result logging.

Differences to the library's Select: errors raised while rows are streamed now reach the consumer
(the library swallowed them, which is what the transacted read was working around), resources are
released before completion is signalled downstream, and query strings are no longer scanned for
?/:name placeholders (ldproxy never binds parameters).

With no user left, the rxjava3-jdbc dependency, the Database in SqlConnectorRx and the unused
SqlDbmsAdapter.getRxType() are removed.

Why the library is not missed

rxjava3-jdbc is a general-purpose reactive JDBC wrapper; ldproxy used a narrow slice of it, and
that slice is exactly what the ~60 lines in SqlClientRx now do directly. Feature by feature:

rxjava3-jdbc capability	use in ldproxy	after this PR
Non-blocking connection pool (Pools.nonBlocking())	never used — the Database was created with fromBlocking(hikariDataSource), so every read ran synchronously on the subscribing thread	unchanged: lease, execute and read run on the subscribing thread; subscribeOn where parallelism is wanted
Parameter binding (?, :name, collection expansion, statement reuse across parameter groups)	never used — every statement arrives as a fully rendered string; the library still parsed each one for placeholders	not needed; no parsing of the SQL text (a latent hazard with a literal ?, e.g. the JSONB ? operator, is gone)
Row mapping (auto-mapping to interfaces/tuples, ResultSetMapper)	not used beyond passing our own SqlRowVals.read(ResultSet, options)	same mapper called directly
Transactions (transacted(), Tx, dependsOn, returnGeneratedKeys)	the write path (removed in PR 1); for reads only to obtain a server-side cursor	setAutoCommit(false) + setFetchSize do that in two lines
Batching, stored procedures (Call), pool health-check queries (DatabaseType)	never used (getRxType() had no caller)	removed
Query timeout	passed as 0 (none)	none (the read-stall timeout covers the stall case)
Resource lifecycle	Flowable.using(prepare, generate over rs.next(), close) — the same structure as the new code — but with the transacted variant's reference counting on top, which releases only on natural completion	Flowable.using + Flowable.generate without the counter: release on completion, error and cancel

So the library provided no capability the read path used that plain JDBC under RxJava does not
provide equally; what it added on top was the reference-counted transaction handling that caused
the leak, an SQL placeholder parser we did not need, the swallowed streaming error (#1293), and a
fork (0.1.4-ii.1) to maintain. The reactive contract of the read path — a backpressured
Flowable<SqlRow>, one connection per subscription, cancellation from downstream — is provided by
RxJava itself and is unchanged.

Verification

• SqlClientRxSpec: streamed and paged reads release statement, result set and connection on
  completion, on cancellation, on a failing next(), on a failing execute and on a failed lease;
  run() and session paths.
• End to end: ordinary reads (items with counts, paging, bbox, single feature, HTML, extents)
  unchanged; six large reads aborted by a throttled client mid-stream returned their connection
  every time (pool at baseline, HikariCP total equal to the database's backend count); the
  search/result-set and stored-query smoke tests — which include a header-only read of a
  100k-feature stored query, i.e. a cancelled streamed read — and the transaction smoke tests pass.

[cportele]

Closes the last variant of the connection leak behind ldproxy/ldproxy#1761 — on the read path this
time — and, with no user left, removes the rxjava3-jdbc dependency. This goes beyond
ldproxy/ldproxy#1645, whose "remove usage of rxjava3-jdbc" concerns the SQL mutations and is
covered by #624.

Problem

Streamed reads — a positive fetch size, as used by single-shot queries — ran in a rxjava3-jdbc
transacted select, which commits and releases the connection only once the rows are exhausted.
An error while reading, or a cancellation (the read-stall timeout from #606, a client that went
away), left the connection leased for good.

Change

All reads lease a connection from the pool and stream the result set with Flowable.using +
Flowable.generate; statement, result set and connection are released on completion, error and
cancellation alike. A read with a fetch size still runs in a transaction so the driver uses a
server-side cursor (ended with a rollback, the cheapest way to close the cursor). Everything
reactive is unchanged: backpressure, execution on the subscribing thread, subscribeOn for
parallel single-shot sub-queries, the read-stall timeout, the SQL result logging.

Differences to the library's Select: errors raised while rows are streamed now reach the consumer
(the library swallowed them, which is what the transacted read was working around), resources are
released before completion is signalled downstream, and query strings are no longer scanned for
?/:name placeholders (ldproxy never binds parameters).

With no user left, the rxjava3-jdbc dependency, the Database in SqlConnectorRx and the unused
SqlDbmsAdapter.getRxType() are removed.

Why the library is not missed

rxjava3-jdbc is a general-purpose reactive JDBC wrapper; ldproxy used a narrow slice of it, and
that slice is exactly what the ~60 lines in SqlClientRx now do directly. Feature by feature:

rxjava3-jdbc capability	use in ldproxy	after this PR
Non-blocking connection pool (Pools.nonBlocking())	never used — the Database was created with fromBlocking(hikariDataSource), so every read ran synchronously on the subscribing thread	unchanged: lease, execute and read run on the subscribing thread; subscribeOn where parallelism is wanted
Parameter binding (?, :name, collection expansion, statement reuse across parameter groups)	never used — every statement arrives as a fully rendered string; the library still parsed each one for placeholders	not needed; no parsing of the SQL text (a latent hazard with a literal ?, e.g. the JSONB ? operator, is gone)
Row mapping (auto-mapping to interfaces/tuples, ResultSetMapper)	not used beyond passing our own SqlRowVals.read(ResultSet, options)	same mapper called directly
Transactions (transacted(), Tx, dependsOn, returnGeneratedKeys)	the write path (removed in PR 1); for reads only to obtain a server-side cursor	setAutoCommit(false) + setFetchSize do that in two lines
Batching, stored procedures (Call), pool health-check queries (DatabaseType)	never used (getRxType() had no caller)	removed
Query timeout	passed as 0 (none)	none (the read-stall timeout covers the stall case)
Resource lifecycle	Flowable.using(prepare, generate over rs.next(), close) — the same structure as the new code — but with the transacted variant's reference counting on top, which releases only on natural completion	Flowable.using + Flowable.generate without the counter: release on completion, error and cancel

So the library provided no capability the read path used that plain JDBC under RxJava does not
provide equally; what it added on top was the reference-counted transaction handling that caused
the leak, an SQL placeholder parser we did not need, the swallowed streaming error (#1293), and a
fork (0.1.4-ii.1) to maintain. The reactive contract of the read path — a backpressured
Flowable<SqlRow>, one connection per subscription, cancellation from downstream — is provided by
RxJava itself and is unchanged.

Verification

• SqlClientRxSpec: streamed and paged reads release statement, result set and connection on
  completion, on cancellation, on a failing next(), on a failing execute and on a failed lease;
  run() and session paths.
• End to end: ordinary reads (items with counts, paging, bbox, single feature, HTML, extents)
  unchanged; six large reads aborted by a throttled client mid-stream returned their connection
  every time (pool at baseline, HikariCP total equal to the database's backend count); the
  search/result-set and stored-query smoke tests — which include a header-only read of a
  100k-feature stored query, i.e. a cancelled streamed read — and the transaction smoke tests pass.

[cportele]

Closes the last variant of the connection leak behind ldproxy/ldproxy#1761 — on the read path this
time — and, with no user left, removes the rxjava3-jdbc dependency. This goes beyond
ldproxy/ldproxy#1645, whose "remove usage of rxjava3-jdbc" concerns the SQL mutations and is
covered by #624.

Problem

Streamed reads — a positive fetch size, as used by single-shot queries — ran in a rxjava3-jdbc
transacted select, which commits and releases the connection only once the rows are exhausted.
An error while reading, or a cancellation (the read-stall timeout from #606, a client that went
away), left the connection leased for good.

Change

All reads lease a connection from the pool and stream the result set with Flowable.using +
Flowable.generate; statement, result set and connection are released on completion, error and
cancellation alike. A read with a fetch size still runs in a transaction so the driver uses a
server-side cursor (ended with a rollback, the cheapest way to close the cursor). Everything
reactive is unchanged: backpressure, execution on the subscribing thread, subscribeOn for
parallel single-shot sub-queries, the read-stall timeout, the SQL result logging.

Differences to the library's Select: errors raised while rows are streamed now reach the consumer
(the library swallowed them, which is what the transacted read was working around), resources are
released before completion is signalled downstream, and query strings are no longer scanned for
?/:name placeholders (ldproxy never binds parameters).

With no user left, the rxjava3-jdbc dependency, the Database in SqlConnectorRx and the unused
SqlDbmsAdapter.getRxType() are removed.

Why the library is not missed

rxjava3-jdbc is a general-purpose reactive JDBC wrapper; ldproxy used a narrow slice of it, and
that slice is exactly what the ~60 lines in SqlClientRx now do directly. Feature by feature:

rxjava3-jdbc capability	use in ldproxy	after this PR
Non-blocking connection pool (Pools.nonBlocking())	never used — the Database was created with fromBlocking(hikariDataSource), so every read ran synchronously on the subscribing thread	unchanged: lease, execute and read run on the subscribing thread; subscribeOn where parallelism is wanted
Parameter binding (?, :name, collection expansion, statement reuse across parameter groups)	never used — every statement arrives as a fully rendered string; the library still parsed each one for placeholders	not needed; no parsing of the SQL text (a latent hazard with a literal ?, e.g. the JSONB ? operator, is gone)
Row mapping (auto-mapping to interfaces/tuples, ResultSetMapper)	not used beyond passing our own SqlRowVals.read(ResultSet, options)	same mapper called directly
Transactions (transacted(), Tx, dependsOn, returnGeneratedKeys)	the write path (removed in PR 1); for reads only to obtain a server-side cursor	setAutoCommit(false) + setFetchSize do that in two lines
Batching, stored procedures (Call), pool health-check queries (DatabaseType)	never used (getRxType() had no caller)	removed
Query timeout	passed as 0 (none)	none (the read-stall timeout covers the stall case)
Resource lifecycle	Flowable.using(prepare, generate over rs.next(), close) — the same structure as the new code — but with the transacted variant's reference counting on top, which releases only on natural completion	Flowable.using + Flowable.generate without the counter: release on completion, error and cancel

So the library provided no capability the read path used that plain JDBC under RxJava does not
provide equally; what it added on top was the reference-counted transaction handling that caused
the leak, an SQL placeholder parser we did not need, the swallowed streaming error (#1293), and a
fork (0.1.4-ii.1) to maintain. The reactive contract of the read path — a backpressured
Flowable<SqlRow>, one connection per subscription, cancellation from downstream — is provided by
RxJava itself and is unchanged.

Verification

• SqlClientRxSpec: streamed and paged reads release statement, result set and connection on
  completion, on cancellation, on a failing next(), on a failing execute and on a failed lease;
  run() and session paths.
• End to end: ordinary reads (items with counts, paging, bbox, single feature, HTML, extents)
  unchanged; six large reads aborted by a throttled client mid-stream returned their connection
  every time (pool at baseline, HikariCP total equal to the database's backend count); the
  search/result-set and stored-query smoke tests — which include a header-only read of a
  100k-feature stored query, i.e. a cancelled streamed read — and the transaction smoke tests pass.

[cportele]

Closes the last variant of the connection leak behind ldproxy/ldproxy#1761 — on the read path this
time — and, with no user left, removes the rxjava3-jdbc dependency. This goes beyond
ldproxy/ldproxy#1645, whose "remove usage of rxjava3-jdbc" concerns the SQL mutations and is
covered by #624.

Problem

Streamed reads — a positive fetch size, as used by single-shot queries — ran in a rxjava3-jdbc
transacted select, which commits and releases the connection only once the rows are exhausted.
An error while reading, or a cancellation (the read-stall timeout from #606, a client that went
away), left the connection leased for good.

Change

All reads lease a connection from the pool and stream the result set with Flowable.using +
Flowable.generate; statement, result set and connection are released on completion, error and
cancellation alike. A read with a fetch size still runs in a transaction so the driver uses a
server-side cursor (ended with a rollback, the cheapest way to close the cursor). Everything
reactive is unchanged: backpressure, execution on the subscribing thread, subscribeOn for
parallel single-shot sub-queries, the read-stall timeout, the SQL result logging.

Differences to the library's Select: errors raised while rows are streamed now reach the consumer
(the library swallowed them, which is what the transacted read was working around), resources are
released before completion is signalled downstream, and query strings are no longer scanned for
?/:name placeholders (ldproxy never binds parameters).

With no user left, the rxjava3-jdbc dependency, the Database in SqlConnectorRx and the unused
SqlDbmsAdapter.getRxType() are removed.

Why the library is not missed

rxjava3-jdbc is a general-purpose reactive JDBC wrapper; ldproxy used a narrow slice of it, and
that slice is exactly what the ~60 lines in SqlClientRx now do directly. Feature by feature:

rxjava3-jdbc capability	use in ldproxy	after this PR
Non-blocking connection pool (Pools.nonBlocking())	never used — the Database was created with fromBlocking(hikariDataSource), so every read ran synchronously on the subscribing thread	unchanged: lease, execute and read run on the subscribing thread; subscribeOn where parallelism is wanted
Parameter binding (?, :name, collection expansion, statement reuse across parameter groups)	never used — every statement arrives as a fully rendered string; the library still parsed each one for placeholders	not needed; no parsing of the SQL text (a latent hazard with a literal ?, e.g. the JSONB ? operator, is gone)
Row mapping (auto-mapping to interfaces/tuples, ResultSetMapper)	not used beyond passing our own SqlRowVals.read(ResultSet, options)	same mapper called directly
Transactions (transacted(), Tx, dependsOn, returnGeneratedKeys)	the write path (removed in PR 1); for reads only to obtain a server-side cursor	setAutoCommit(false) + setFetchSize do that in two lines
Batching, stored procedures (Call), pool health-check queries (DatabaseType)	never used (getRxType() had no caller)	removed
Query timeout	passed as 0 (none)	none (the read-stall timeout covers the stall case)
Resource lifecycle	Flowable.using(prepare, generate over rs.next(), close) — the same structure as the new code — but with the transacted variant's reference counting on top, which releases only on natural completion	Flowable.using + Flowable.generate without the counter: release on completion, error and cancel

So the library provided no capability the read path used that plain JDBC under RxJava does not
provide equally; what it added on top was the reference-counted transaction handling that caused
the leak, an SQL placeholder parser we did not need, the swallowed streaming error (#1293), and a
fork (0.1.4-ii.1) to maintain. The reactive contract of the read path — a backpressured
Flowable<SqlRow>, one connection per subscription, cancellation from downstream — is provided by
RxJava itself and is unchanged.

Verification

• SqlClientRxSpec: streamed and paged reads release statement, result set and connection on
  completion, on cancellation, on a failing next(), on a failing execute and on a failed lease;
  run() and session paths.
• End to end: ordinary reads (items with counts, paging, bbox, single feature, HTML, extents)
  unchanged; six large reads aborted by a throttled client mid-stream returned their connection
  every time (pool at baseline, HikariCP total equal to the database's backend count); the
  search/result-set and stored-query smoke tests — which include a header-only read of a
  100k-feature stored query, i.e. a cancelled streamed read — and the transaction smoke tests pass.

[cportele]

Closes the last variant of the connection leak behind ldproxy/ldproxy#1761 — on the read path this
time — and, with no user left, removes the rxjava3-jdbc dependency. This goes beyond
ldproxy/ldproxy#1645, whose "remove usage of rxjava3-jdbc" concerns the SQL mutations and is
covered by #624.

Problem

Streamed reads — a positive fetch size, as used by single-shot queries — ran in a rxjava3-jdbc
transacted select, which commits and releases the connection only once the rows are exhausted.
An error while reading, or a cancellation (the read-stall timeout from #606, a client that went
away), left the connection leased for good.

Change

All reads lease a connection from the pool and stream the result set with Flowable.using +
Flowable.generate; statement, result set and connection are released on completion, error and
cancellation alike. A read with a fetch size still runs in a transaction so the driver uses a
server-side cursor (ended with a rollback, the cheapest way to close the cursor). Everything
reactive is unchanged: backpressure, execution on the subscribing thread, subscribeOn for
parallel single-shot sub-queries, the read-stall timeout, the SQL result logging.

Differences to the library's Select: errors raised while rows are streamed now reach the consumer
(the library swallowed them, which is what the transacted read was working around), resources are
released before completion is signalled downstream, and query strings are no longer scanned for
?/:name placeholders (ldproxy never binds parameters).

With no user left, the rxjava3-jdbc dependency, the Database in SqlConnectorRx and the unused
SqlDbmsAdapter.getRxType() are removed.

Why the library is not missed

rxjava3-jdbc is a general-purpose reactive JDBC wrapper; ldproxy used a narrow slice of it, and
that slice is exactly what the ~60 lines in SqlClientRx now do directly. Feature by feature:

rxjava3-jdbc capability	use in ldproxy	after this PR
Non-blocking connection pool (Pools.nonBlocking())	never used — the Database was created with fromBlocking(hikariDataSource), so every read ran synchronously on the subscribing thread	unchanged: lease, execute and read run on the subscribing thread; subscribeOn where parallelism is wanted
Parameter binding (?, :name, collection expansion, statement reuse across parameter groups)	never used — every statement arrives as a fully rendered string; the library still parsed each one for placeholders	not needed; no parsing of the SQL text (a latent hazard with a literal ?, e.g. the JSONB ? operator, is gone)
Row mapping (auto-mapping to interfaces/tuples, ResultSetMapper)	not used beyond passing our own SqlRowVals.read(ResultSet, options)	same mapper called directly
Transactions (transacted(), Tx, dependsOn, returnGeneratedKeys)	the write path (removed in PR 1); for reads only to obtain a server-side cursor	setAutoCommit(false) + setFetchSize do that in two lines
Batching, stored procedures (Call), pool health-check queries (DatabaseType)	never used (getRxType() had no caller)	removed
Query timeout	passed as 0 (none)	none (the read-stall timeout covers the stall case)
Resource lifecycle	Flowable.using(prepare, generate over rs.next(), close) — the same structure as the new code — but with the transacted variant's reference counting on top, which releases only on natural completion	Flowable.using + Flowable.generate without the counter: release on completion, error and cancel

So the library provided no capability the read path used that plain JDBC under RxJava does not
provide equally; what it added on top was the reference-counted transaction handling that caused
the leak, an SQL placeholder parser we did not need, the swallowed streaming error (#1293), and a
fork (0.1.4-ii.1) to maintain. The reactive contract of the read path — a backpressured
Flowable<SqlRow>, one connection per subscription, cancellation from downstream — is provided by
RxJava itself and is unchanged.

Verification

• SqlClientRxSpec: streamed and paged reads release statement, result set and connection on
  completion, on cancellation, on a failing next(), on a failing execute and on a failed lease;
  run() and session paths.
• End to end: ordinary reads (items with counts, paging, bbox, single feature, HTML, extents)
  unchanged; six large reads aborted by a throttled client mid-stream returned their connection
  every time (pool at baseline, HikariCP total equal to the database's backend count); the
  search/result-set and stored-query smoke tests — which include a header-only read of a
  100k-feature stored query, i.e. a cancelled streamed read — and the transaction smoke tests pass.

[cportele]

Closes the last variant of the connection leak behind ldproxy/ldproxy#1761 — on the read path this
time — and, with no user left, removes the rxjava3-jdbc dependency. This goes beyond
ldproxy/ldproxy#1645, whose "remove usage of rxjava3-jdbc" concerns the SQL mutations and is
covered by #624.

Problem

Streamed reads — a positive fetch size, as used by single-shot queries — ran in a rxjava3-jdbc
transacted select, which commits and releases the connection only once the rows are exhausted.
An error while reading, or a cancellation (the read-stall timeout from #606, a client that went
away), left the connection leased for good.

Change

All reads lease a connection from the pool and stream the result set with Flowable.using +
Flowable.generate; statement, result set and connection are released on completion, error and
cancellation alike. A read with a fetch size still runs in a transaction so the driver uses a
server-side cursor (ended with a rollback, the cheapest way to close the cursor). Everything
reactive is unchanged: backpressure, execution on the subscribing thread, subscribeOn for
parallel single-shot sub-queries, the read-stall timeout, the SQL result logging.

Differences to the library's Select: errors raised while rows are streamed now reach the consumer
(the library swallowed them, which is what the transacted read was working around), resources are
released before completion is signalled downstream, and query strings are no longer scanned for
?/:name placeholders (ldproxy never binds parameters).

With no user left, the rxjava3-jdbc dependency, the Database in SqlConnectorRx and the unused
SqlDbmsAdapter.getRxType() are removed.

Why the library is not missed

rxjava3-jdbc is a general-purpose reactive JDBC wrapper; ldproxy used a narrow slice of it, and
that slice is exactly what the ~60 lines in SqlClientRx now do directly. Feature by feature:

rxjava3-jdbc capability	use in ldproxy	after this PR
Non-blocking connection pool (Pools.nonBlocking())	never used — the Database was created with fromBlocking(hikariDataSource), so every read ran synchronously on the subscribing thread	unchanged: lease, execute and read run on the subscribing thread; subscribeOn where parallelism is wanted
Parameter binding (?, :name, collection expansion, statement reuse across parameter groups)	never used — every statement arrives as a fully rendered string; the library still parsed each one for placeholders	not needed; no parsing of the SQL text (a latent hazard with a literal ?, e.g. the JSONB ? operator, is gone)
Row mapping (auto-mapping to interfaces/tuples, ResultSetMapper)	not used beyond passing our own SqlRowVals.read(ResultSet, options)	same mapper called directly
Transactions (transacted(), Tx, dependsOn, returnGeneratedKeys)	the write path (removed in PR 1); for reads only to obtain a server-side cursor	setAutoCommit(false) + setFetchSize do that in two lines
Batching, stored procedures (Call), pool health-check queries (DatabaseType)	never used (getRxType() had no caller)	removed
Query timeout	passed as 0 (none)	none (the read-stall timeout covers the stall case)
Resource lifecycle	Flowable.using(prepare, generate over rs.next(), close) — the same structure as the new code — but with the transacted variant's reference counting on top, which releases only on natural completion	Flowable.using + Flowable.generate without the counter: release on completion, error and cancel

So the library provided no capability the read path used that plain JDBC under RxJava does not
provide equally; what it added on top was the reference-counted transaction handling that caused
the leak, an SQL placeholder parser we did not need, the swallowed streaming error (#1293), and a
fork (0.1.4-ii.1) to maintain. The reactive contract of the read path — a backpressured
Flowable<SqlRow>, one connection per subscription, cancellation from downstream — is provided by
RxJava itself and is unchanged.

Verification

• SqlClientRxSpec: streamed and paged reads release statement, result set and connection on
  completion, on cancellation, on a failing next(), on a failing execute and on a failed lease;
  run() and session paths.
• End to end: ordinary reads (items with counts, paging, bbox, single feature, HTML, extents)
  unchanged; six large reads aborted by a throttled client mid-stream returned their connection
  every time (pool at baseline, HikariCP total equal to the database's backend count); the
  search/result-set and stored-query smoke tests — which include a header-only read of a
  100k-feature stored query, i.e. a cancelled streamed read — and the transaction smoke tests pass.

[cportele]

Closes the last variant of the connection leak behind ldproxy/ldproxy#1761 — on the read path this
time — and, with no user left, removes the rxjava3-jdbc dependency. This goes beyond
ldproxy/ldproxy#1645, whose "remove usage of rxjava3-jdbc" concerns the SQL mutations and is
covered by #624.

Problem

Streamed reads — a positive fetch size, as used by single-shot queries — ran in a rxjava3-jdbc
transacted select, which commits and releases the connection only once the rows are exhausted.
An error while reading, or a cancellation (the read-stall timeout from #606, a client that went
away), left the connection leased for good.

Change

All reads lease a connection from the pool and stream the result set with Flowable.using +
Flowable.generate; statement, result set and connection are released on completion, error and
cancellation alike. A read with a fetch size still runs in a transaction so the driver uses a
server-side cursor (ended with a rollback, the cheapest way to close the cursor). Everything
reactive is unchanged: backpressure, execution on the subscribing thread, subscribeOn for
parallel single-shot sub-queries, the read-stall timeout, the SQL result logging.

Differences to the library's Select: errors raised while rows are streamed now reach the consumer
(the library swallowed them, which is what the transacted read was working around), resources are
released before completion is signalled downstream, and query strings are no longer scanned for
?/:name placeholders (ldproxy never binds parameters).

With no user left, the rxjava3-jdbc dependency, the Database in SqlConnectorRx and the unused
SqlDbmsAdapter.getRxType() are removed.

Why the library is not missed

rxjava3-jdbc is a general-purpose reactive JDBC wrapper; ldproxy used a narrow slice of it, and
that slice is exactly what the ~60 lines in SqlClientRx now do directly. Feature by feature:

rxjava3-jdbc capability	use in ldproxy	after this PR
Non-blocking connection pool (Pools.nonBlocking())	never used — the Database was created with fromBlocking(hikariDataSource), so every read ran synchronously on the subscribing thread	unchanged: lease, execute and read run on the subscribing thread; subscribeOn where parallelism is wanted
Parameter binding (?, :name, collection expansion, statement reuse across parameter groups)	never used — every statement arrives as a fully rendered string; the library still parsed each one for placeholders	not needed; no parsing of the SQL text (a latent hazard with a literal ?, e.g. the JSONB ? operator, is gone)
Row mapping (auto-mapping to interfaces/tuples, ResultSetMapper)	not used beyond passing our own SqlRowVals.read(ResultSet, options)	same mapper called directly
Transactions (transacted(), Tx, dependsOn, returnGeneratedKeys)	the write path (removed in PR 1); for reads only to obtain a server-side cursor	setAutoCommit(false) + setFetchSize do that in two lines
Batching, stored procedures (Call), pool health-check queries (DatabaseType)	never used (getRxType() had no caller)	removed
Query timeout	passed as 0 (none)	none (the read-stall timeout covers the stall case)
Resource lifecycle	Flowable.using(prepare, generate over rs.next(), close) — the same structure as the new code — but with the transacted variant's reference counting on top, which releases only on natural completion	Flowable.using + Flowable.generate without the counter: release on completion, error and cancel

So the library provided no capability the read path used that plain JDBC under RxJava does not
provide equally; what it added on top was the reference-counted transaction handling that caused
the leak, an SQL placeholder parser we did not need, the swallowed streaming error (#1293), and a
fork (0.1.4-ii.1) to maintain. The reactive contract of the read path — a backpressured
Flowable<SqlRow>, one connection per subscription, cancellation from downstream — is provided by
RxJava itself and is unchanged.

Verification

• SqlClientRxSpec: streamed and paged reads release statement, result set and connection on
  completion, on cancellation, on a failing next(), on a failing execute and on a failed lease;
  run() and session paths.
• End to end: ordinary reads (items with counts, paging, bbox, single feature, HTML, extents)
  unchanged; six large reads aborted by a throttled client mid-stream returned their connection
  every time (pool at baseline, HikariCP total equal to the database's backend count); the
  search/result-set and stored-query smoke tests — which include a header-only read of a
  100k-feature stored query, i.e. a cancelled streamed read — and the transaction smoke tests pass.