Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Oracle: Lightweight Connection Validation #1451

Merged
merged 2 commits into from
Aug 21, 2024

Conversation

tsegismont
Copy link
Contributor

See #1450

@tsegismont
Copy link
Contributor Author

Hi @loiclefevre , I would appreciate your advice on this. Is the SOCKET connection validation level appropriate (non-blocking)? Or should we consider something lower, like INBAND_DOWN or LOCAL?

cc @DavideD

@gvenzl
Copy link

gvenzl commented Jul 30, 2024

Hey @tsegismont,

@loiclefevre is on his well-deserved holiday, hence I'm adding @jeandelavarene to this thread to provide guidance on your question about OracleConnection.ConnectionValidation. and which mode to use.

Meanwhile, according to the JavaDoc it would seems indeed that SOCKET does not involve a network call but just checks whether the socket is still alive.

@jeandelavarene
Copy link

jeandelavarene commented Jul 31, 2024

Here is a description of the different validation modes in decreasing order of validation strength:

  • "SERVER" (or "COMPLETE") makes the driver execute a basic SQL query "SELECT 'x' FROM DUAL",
  • "NETWORK" makes the driver issue an OPING TTC function. This is the most lightweight roundtrip to the DB. It's the default validation mode.
  • "SOCKET" makes the driver write a zero-length NS data packet on the socket that is ignored by the server. There is no guarantee that this call will always be non-blocking. It should be non-blocking in most of the cases.
  • "INBAND_DOWN" makes the driver do a non-blocking socket read call on the socket
  • "LOCAL" same as above
  • "NONE" just checks the connection's lifecycle (variable check)

Note that, for example, a "SOCKET" validation may return a false positive (it may not always detect all socket defects). On the other hand, a "SOCKET" validation is much faster than "NETWORK". In most cases, we recommend using "SOCKET" validation at connection borrow (in UCP for example). For applications that can't tolerate an error on the connection, turning on "SERVER" or "NETWORK" would be more appropriate.

CC @gvenzl

@vietj vietj added this to the 5.0.0 milestone Jul 31, 2024
@tsegismont tsegismont removed this from the 5.0.0 milestone Aug 21, 2024
See eclipse-vertx#1450

Signed-off-by: Thomas Segismont <tsegismont@gmail.com>
@tsegismont
Copy link
Contributor Author

Thank you @gvenzl and @jeandelavarene

In this part of our code we can't tolerate the driver to block (event not every time). And for the other clients (Pg, MySQL, ...etc) where Vert.x manages the connection, we only check the connection's lifecycle (variable check):

So I think the appropriate setting is NONE in our case. This will provide the same experience as with other clients.

This setting does not make the driver block and is implemented as a simple lifecycle check.

This is exactly what we do with other clients (Pg, MySQL, ...etc).

Signed-off-by: Thomas Segismont <tsegismont@gmail.com>
@tsegismont tsegismont merged commit 15bdebe into eclipse-vertx:master Aug 21, 2024
15 checks passed
@tsegismont tsegismont deleted the issue/1450 branch August 21, 2024 16:47
tsegismont added a commit that referenced this pull request Aug 21, 2024
* Oracle: Lightweight Connection Validation

See #1450

Signed-off-by: Thomas Segismont <tsegismont@gmail.com>

* Use NONE Connection validation.

This setting does not make the driver block and is implemented as a simple lifecycle check.

This is exactly what we do with other clients (Pg, MySQL, ...etc).

Signed-off-by: Thomas Segismont <tsegismont@gmail.com>

---------

Signed-off-by: Thomas Segismont <tsegismont@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants