Skip to content

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

Merged
merged 5 commits into from
Jun 17, 2025

Conversation

komamitsu
Copy link
Contributor

@komamitsu komamitsu commented Jun 13, 2025

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

  • Close the connection for Scan operation in JdbcDatabase.scan() whenever an exception is thrown not only when SQLException is thrown, since IllegalArgumentException can be thrown when the target table doesn't exist

Checklist

The following is a best-effort checklist. If any items in this checklist are not applicable to this PR or are dependent on other, unmerged PRs, please still mark the checkboxes after you have read and understood each item.

  • I have commented my code, particularly in hard-to-understand areas.
  • I have updated the documentation to reflect the changes.
  • I have considered whether similar issues could occur in other products, components, or modules if this PR is for bug fixes.
  • Any remaining open issues linked to this PR are documented and up-to-date (Jira, GitHub, etc.).
  • Tests (unit, integration, etc.) have been added for the changes.
  • My changes generate no new warnings.
  • Any dependent changes in other PRs have been merged and published.

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

when the target table is not found
@komamitsu komamitsu self-assigned this Jun 13, 2025
@komamitsu komamitsu requested a review from Copilot June 13, 2025 07:54
Copy link

@Copilot Copilot AI left a 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) {

@komamitsu komamitsu marked this pull request as draft June 13, 2025 09:10
@komamitsu komamitsu marked this pull request as draft June 13, 2025 09:10
@komamitsu
Copy link
Contributor Author

komamitsu commented Jun 13, 2025

The current fix changes the bahavior a bit. Let me update this PR.

Fixed it.

@komamitsu komamitsu marked this pull request as ready for review June 13, 2025 09:50
Copy link
Contributor

@Torch3333 Torch3333 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thank you!

Copy link
Collaborator

@brfrn169 brfrn169 left a 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!

Comment on lines 121 to 123
if (connection != null) {
close(connection);
}
Copy link
Collaborator

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:

Suggested change
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) {
Copy link
Collaborator

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?

Copy link
Contributor Author

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.

Copy link
Collaborator

@brfrn169 brfrn169 left a 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) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@brfrn169 I took care of this similar potential leak in f18d40f.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

Copy link
Contributor

@feeblefakie feeblefakie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Thank you!

@komamitsu komamitsu merged commit 644578b into master Jun 17, 2025
106 of 107 checks passed
@komamitsu komamitsu deleted the close-scanner-conn-if-table-does-not-exist branch June 17, 2025 04:19
feeblefakie added a commit that referenced this pull request Jun 17, 2025
…ation fails because the target table doesn't exist (#2766)

Co-authored-by: Hiroyuki Yamada <[email protected]>
komamitsu added a commit that referenced this pull request Jun 17, 2025
…ation fails because the target table doesn't exist (#2766)

Co-authored-by: Hiroyuki Yamada <[email protected]>
komamitsu added a commit that referenced this pull request Jun 17, 2025
…ation fails because the target table doesn't exist (#2766)

Co-authored-by: Hiroyuki Yamada <[email protected]>
komamitsu added a commit that referenced this pull request Jun 17, 2025
…ation fails because the target table doesn't exist (#2766)

Co-authored-by: Hiroyuki Yamada <[email protected]>
komamitsu added a commit that referenced this pull request Jun 17, 2025
…ation fails because the target table doesn't exist (#2766)

Co-authored-by: Hiroyuki Yamada <[email protected]>
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