We currently have an issue where the database might throw unexpected exceptions. To handle that we would like to catch those exceptions and close the connection to the database. I.e we need to add this code:
@Override
public <T> Mono<T> inConnection(Function<Connection, Mono<T>> action) throws DataAccessException {
return super.inConnection(con -> action.apply(con)
.onErrorResume(e -> {
handleError(e, con);
return Mono.error(e);
}));
}
@Override
public <T> Flux<T> inConnectionMany(Function<Connection, Flux<T>> action) throws DataAccessException {
return super.inConnectionMany(con -> action.apply(con)
.onErrorResume(e -> {
handleError(e, con);
return Mono.error(e);
}));
}
However since DefaultDatabaseClient is package private it is not possible to extend it.
The easiest solution would be to add a delegating client which just delegates all calls to the underlying client and adds that error handling on top. However the internal call structure of DefaultDatabaseClient makes that impossible. Calls to the "sql" method returns an instance of the internal class DefaultGenericExecuteSpec. Since that class is an internal class it has a reference to the DefaultDatabaseClient, that reference gets exposed externally and when a client calls the "map" method on the ExecuteSpec. That reference is used to create an FetchSpec and then the FetchSpec will use that reference to fetch the data, not the delegating client completely bypassing the custom error handling.
I propose to expose DefaultGenericExecuteSpec externally and let the caller provide a client with which to do the requests. Then a delegating client could create a new instance with itself as client.
Comment From: jhoeller
Could we add this to DatabaseClient
itself as an error handling strategy? Configurable on DatabaseClient.Builder
, so not requiring to make DefaultDatabaseClient
public?
Comment From: magnus-lundberg-discovery
Sure that would be even better of course :)
Comment From: injae-kim
Happy new year @jhoeller ! I create PR https://github.com/spring-projects/spring-framework/pull/31942 to resolve this issue~!
Waiting your awesome code review 😄
Comment From: snicoll
@magnus-lundberg-discovery we had a PR for this but we're not sure that we need to head in this direction. Mark asked a question that might help us find out, see https://github.com/spring-projects/spring-framework/pull/31942#issuecomment-1876869472.
To move forward with your request, please share a small sample with a representative sample of what you're trying to achieve. You can attach a zip to this issue or push the code to a GitHub repository.
Comment From: spring-projects-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: spring-projects-issues
Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.