Expose the shared attribute in the reactive data source configuration

[cescoffier]

This attribute was introduced in Vert.x 4.2.2.

[quarkus-bot]

This workflow status is outdated as a new workflow run has been triggered.

Failing Jobs - Building d9de188

Status	Name	Step	Failures	Logs	Raw logs
✖	Initial JDK 11 Build	Build	Failures	Logs	Raw logs

Failures

⚙️ Initial JDK 11 Build #

- Failing: extensions/reactive-db2-client/runtime 
! Skipped: devtools/bom-descriptor-json docs extensions/reactive-db2-client/deployment and 3 more

📦 extensions/reactive-db2-client/runtime

✖ Failed to execute goal net.revelc.code.formatter:formatter-maven-plugin:2.17.1:validate (default) on project quarkus-reactive-db2-client: File '/home/runner/work/quarkus/quarkus/extensions/reactive-db2-client/runtime/src/main/java/io/quarkus/reactive/db2/client/runtime/DB2PoolRecorder.java' has not been previously formatted. Please format file and commit before running validation!

[geoand]

This needs a formatting change

[gsmet]

I rebased and adjusted a small thing in the javadoc. Otherwise, it looks good to go!

[Sanne]

I can't say I understand how to use this... is there a better explanation in the vertx docs?

I found this one but I'm not sure how this translates to Quarkus users as it seems very specific to vert.x:
-https://vertx.io/docs/vertx-pg-client/java/#_pool_sharing

[gsmet]

@cescoffier could you have a look at @Sanne 's question?

[cescoffier]

@Sanne it allows sharing the connection pool. It can be useful when you do not use Hibernate Reactive :-).
Now, it's a pretty advanced use case.

[Sanne]

Sorry I might be slow (and I'm away) but I still don't understand the implications a Quarkus user should understand.

"shared" across what? What kind of usage pattern would require this to be set (or not)? The documentation I found is very specific for a Vert.x application - I'm not sure how that translates to a Quarkus application and we need to document that in a way which a typical Quarkus user can understand.

In particular I'd want to explore if we actually need a property, or if something should be enforced or inferred.

[gavinking]

@cescoffier I don't understand this concept either:

share the pool among datasources.

You mean, something like: connections to different databases might go into one big pool? Or something else?

[gavinking]

Whatever, the documentation should read something like:

/**
 * True when the database connection pool is shared among datasources.
 * 
 * If, false, the default, there is a separate connection pool for each named datasource.
 * Otherwise, if true, there is a single connection pool holding every pooled connection 
 * from any datasource, with a single FIFO eviction queue and blah blah blah blah blah.
 */

Where blah blah blah blah blah explains all the implications of enabling this pretty unintuitive setting.