-
Notifications
You must be signed in to change notification settings - Fork 38
Fix potential connection leak when using jdbc
storage and Scan operation fails because the target table doesn't exist
#2766
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
Conversation
when the target table is not found
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR fixes a potential connection leak in the JDBC storage layer when a Scan operation fails due to a missing target table. The changes ensure the connection is rolled back and closed regardless of the exception type.
- Update JdbcDatabase.scan() to catch Exception instead of only SQLException.
- Add a new test case in JdbcDatabaseTest.java to verify that an IllegalArgumentException thrown by the JDBC service results in an ExecutionException and proper cleanup.
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
File | Description |
---|---|
core/src/test/java/com/scalar/db/storage/jdbc/JdbcDatabaseTest.java | Added test case to simulate table-not-found scenario and verify connection rollback and closure. |
core/src/main/java/com/scalar/db/storage/jdbc/JdbcDatabase.java | Modified exception handling in the scan method to catch a broader range of exceptions. |
Comments suppressed due to low confidence (1)
core/src/main/java/com/scalar/db/storage/jdbc/JdbcDatabase.java:108
- Catching a broad Exception may inadvertently hide unexpected errors. Consider catching only the specific exceptions you intend to handle, or add logging to clearly indicate that an unexpected exception was caught.
} catch (Exception e) {
Fixed it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch! Left a few comments. Please take a look when you have time!
if (connection != null) { | ||
close(connection); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The null handling is already done in the close()
method, so we don't need to do that here:
if (connection != null) { | |
close(connection); | |
} | |
close(connection); |
@@ -117,6 +117,11 @@ public Scanner scan(Scan scan) throws ExecutionException { | |||
close(connection); | |||
throw new ExecutionException( | |||
CoreError.JDBC_ERROR_OCCURRED_IN_SELECTION.buildMessage(e.getMessage()), e); | |||
} catch (Exception e) { | |||
if (connection != null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't we need to connection.rollback()
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I focused on the connection leak, but I think the transaction should be rolled-back immediately to avoid potential future lazy-recovery. Addressed it in e96888e.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thank you!
@@ -197,6 +197,9 @@ public void mutate(List<? extends Mutation> mutations) throws ExecutionException | |||
close(connection); | |||
throw new ExecutionException( | |||
CoreError.JDBC_ERROR_OCCURRED_IN_MUTATION.buildMessage(e.getMessage()), e); | |||
} catch (Exception e) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thank you!
…ation fails because the target table doesn't exist (#2766) Co-authored-by: Hiroyuki Yamada <[email protected]>
…ation fails because the target table doesn't exist (#2766) Co-authored-by: Hiroyuki Yamada <[email protected]>
…ation fails because the target table doesn't exist (#2766) Co-authored-by: Hiroyuki Yamada <[email protected]>
…ation fails because the target table doesn't exist (#2766) Co-authored-by: Hiroyuki Yamada <[email protected]>
…ation fails because the target table doesn't exist (#2766) Co-authored-by: Hiroyuki Yamada <[email protected]>
Description
I found the current
com.scalar.db.storage.jdbc.JdbcDatabase#scan
doesn't close the connection when the target table doesn't exist. This PR fixes the issue.Related issues and/or PRs
None
Changes made
JdbcDatabase.scan()
whenever an exception is thrown not only when SQLException is thrown, sinceIllegalArgumentException
can be thrown when the target table doesn't existChecklist
Additional notes (optional)
None
Release notes
Fixed potential connection leak when using
jdbc
storage and Scan operation fails because the target table doesn't exist