Skip to content

Conversation

@Torch3333
Copy link
Contributor

@Torch3333 Torch3333 commented Oct 20, 2025

Description

When the JDBC transaction manager is used, we set the default transaction isolation level to SERIALIZABLE if the user does not specify one in the config with scalar.db.jdbc.isolation_level.
We now consider this is not necessary anymore and the default storage transaction isolation can be used if scalar.db.jdbc.isolation_level is not set.

Related issues and/or PRs

Changes made

  • For the JDBC transaction manager, do not set the SERIALIZABLE transaction isolation level by default. The transaction isolation level is set by the storage.

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)

N/A

Release notes

When using the JDBC transaction manager, do not set the JDBC transaction isolation level to SERIALIZABLE when the configuration scalar.db.jdbc.isolation_level is not set. The default is now the default value set by the storage.

…lt transaction isolation level to SERIALIZABLE by default, use the default storage setting
@Torch3333 Torch3333 self-assigned this Oct 20, 2025
@Torch3333 Torch3333 changed the title WIth the JDBC transaction manager, use the storage default transaction isolatation level instead of SERIALIZABLE WIth the JDBC transaction manager, use the storage default transaction isolation level instead of SERIALIZABLE Oct 20, 2025
@Torch3333 Torch3333 mentioned this pull request Oct 20, 2025
7 tasks
@Torch3333 Torch3333 marked this pull request as ready for review October 20, 2025 06:21
@Torch3333 Torch3333 requested review from a team, brfrn169, Copilot, feeblefakie and komamitsu and removed request for a team October 20, 2025 06:21
Copy link
Contributor

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 changes the default transaction isolation level behavior for JDBC transaction manager. Instead of forcing SERIALIZABLE isolation level when scalar.db.jdbc.isolation_level is not configured, it now allows the storage to use its own default transaction isolation level.

Key Changes

  • Removed the hardcoded SERIALIZABLE transaction isolation level setting from the JDBC data source initialization
  • Transaction isolation level now defaults to the storage's native default when not explicitly configured

Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.

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!

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!

Copy link
Contributor

@komamitsu komamitsu 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!

@brfrn169 brfrn169 merged commit 7a2d999 into master Oct 21, 2025
115 of 116 checks passed
@brfrn169 brfrn169 deleted the jdbc_transaction_manager_do_not_set_serializable_transaction_isolation_level branch October 21, 2025 10:49
feeblefakie pushed a commit that referenced this pull request Oct 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants