bugfix: Fixed that the same record has different lowkeys due to mixed case of table names #6678
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 2.x #6678 +/- ##
============================================
+ Coverage 50.84% 50.86% +0.02%
- Complexity 5831 5836 +5
============================================
Files 1051 1051
Lines 36325 36341 +16
Branches 4317 4321 +4
============================================
+ Hits 18468 18486 +18
+ Misses 16003 15995 -8
- Partials 1854 1860 +6
|
funky-eyes
changed the title
funky-eyes
approved these changes
Jul 16, 2024
funky-eyes
added
type: bug
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ⅰ. Describe what this PR did
When the database is case-insensitive, if different services use table names with different case to query the same record, the lock RowKey will be inconsistent, causing the same global transaction lock to fail to re-enter. This PR unifies the record table name of TableMetaCache with the actual converted table name to avoid this situation.
Ⅱ. Does this pull request fix one issue?
fixes #6612
Ⅲ. Why don't you add test cases (unit test/integration test)?
Ⅳ. Describe how to verify it
Seata Version: 2.0.0
Database: oracle-xe-11g with JDBC ojdbc6:11.2.0.4.0
How to reproduce? using Oracle database as an example. In a GlobalTransactional
Service A: Use SQL1 - update stock_tbl set count = count - ? where id= "1"
Service B: Use SQL2 - update stock_TBL set count = count - ? where id = "1"
The RowKey generated by service A is resourceId^^^stock_tbl^^^1, while service B is resourceId^^^stock_TBL^^^1
The result is that Service A cannot acquire global lock.
Using the same case, the transaction can be committed normally after modification
Ⅴ. Special notes for reviews
It should be noted that after upgrading, if there are uncleared locks in the old version, there may be lock conflicts, causing transactions to roll back.