Optimize OVS tunnel sequence numbers to use atomic SQL instead of row-level locks#13443
Optimize OVS tunnel sequence numbers to use atomic SQL instead of row-level locks#13443nvazquez wants to merge 1 commit into
Conversation
…-level locks Replace lockRow + Java increment + update pattern in getNextTopologyUpdateSequenceNumber and getNextRoutingPolicyUpdateSequenceNumber with atomic SQL using LAST_INSERT_ID: UPDATE ... SET seq_no = LAST_INSERT_ID(seq_no + 1) WHERE id = ? SELECT LAST_INSERT_ID() InnoDB serializes concurrent UPDATEs on the same row, and LAST_INSERT_ID(expr) stores the result in connection-local state, so each caller gets a unique monotonically increasing value without explicit row locks. Also captures the return value of persist() in the find-or-create initialization path — the original code discarded it, relying on reflection to populate the ID field on the original object. Removes the empty try/finally blocks from both methods.
|
@blueorangutan package |
|
@nvazquez a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 4.22 #13443 +/- ##
============================================
- Coverage 17.67% 17.67% -0.01%
- Complexity 15792 15793 +1
============================================
Files 5922 5922
Lines 533167 533174 +7
Branches 65210 65211 +1
============================================
- Hits 94246 94244 -2
- Misses 428276 428284 +8
- Partials 10645 10646 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 18290 |
|
@blueorangutan test |
|
@nvazquez a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
|
[SF] Trillian test result (tid-16361)
|
Description
This PR replaces lockRow + Java increment + update pattern in getNextTopologyUpdateSequenceNumber and
getNextRoutingPolicyUpdateSequenceNumber with atomic SQL using LAST_INSERT_ID:
UPDATE ... SET seq_no = LAST_INSERT_ID(seq_no + 1) WHERE id = ?
SELECT LAST_INSERT_ID()
InnoDB serializes concurrent UPDATEs on the same row, and LAST_INSERT_ID(expr) stores the result in connection-local state, so each caller gets a unique monotonically increasing value without explicit row locks.
Also captures the return value of persist() in the find-or-create initialization path — the original code discarded it, relying on reflection to populate the ID field on the original object.
Removes the empty try/finally blocks from both methods.
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
How did you try to break this feature and the system with this change?