refactor: avoid redundant DB calls when checking for root admin account#11390
refactor: avoid redundant DB calls when checking for root admin account#11390shwstppr wants to merge 17 commits intoapache:mainfrom
Conversation
AccountService.isRootAdmin(Long) is currently invoked each time to check if an account or caller is a root admin, leading to repeated DB lookups. In most cases, the Account object is already available and should be used directly. For the caller, the root admin flag is now cached in CallContext to avoid repeated evaluations. Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #11390 +/- ##
============================================
+ Coverage 3.67% 17.89% +14.22%
- Complexity 0 16088 +16088
============================================
Files 452 5936 +5484
Lines 38379 532589 +494210
Branches 7100 65146 +58046
============================================
+ Hits 1410 95310 +93900
- Misses 36783 426613 +389830
- Partials 186 10666 +10480
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
|
@blueorangutan package |
|
@shwstppr 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. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 14546 |
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
|
@blueorangutan package |
|
@shwstppr 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. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 14552 |
|
@blueorangutan package |
|
@shwstppr 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. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 14558 |
|
@blueorangutan test |
|
@shwstppr a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
|
[SF] Trillian test result (tid-14035)
|
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 82 out of 82 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| public boolean isCallingAccountRootAdmin() { | ||
| if (isAccountRootAdmin == null) { | ||
| AccountService accountService; | ||
| try { | ||
| accountService = ComponentContext.getDelegateComponentOfType(AccountService.class); | ||
| } catch (NoSuchBeanDefinitionException e) { | ||
| LOGGER.warn("Falling back to account type check for isRootAdmin for account ID: {} as no AccountService bean found: {}", accountId, e.getMessage()); | ||
| Account caller = getCallingAccount(); | ||
| return caller != null && caller.getType() == Account.Type.ADMIN; | ||
| } | ||
| isAccountRootAdmin = accountService.isRootAdmin(getCallingAccount()); | ||
| } | ||
| return Boolean.TRUE.equals(isAccountRootAdmin); | ||
| } |
There was a problem hiding this comment.
The fallback logic at line 149 returns the result directly without caching it in isAccountRootAdmin. This means if AccountService is unavailable, subsequent calls will repeat the check instead of using the cached value. Either cache the result before returning, or document this as intentional behavior.
| LOGGER.warn("Falling back to account type check for isRootAdmin for account ID: {} as no AccountService bean found: {}", accountId, e.getMessage()); | ||
| Account caller = getCallingAccount(); | ||
| return caller != null && caller.getType() == Account.Type.ADMIN; |
There was a problem hiding this comment.
The fallback check caller.getType() == Account.Type.ADMIN is inconsistent with the actual root admin check performed by AccountService, which uses security checkers. This could lead to different behavior when AccountService is unavailable. Consider removing the fallback entirely or throwing an exception to fail fast when AccountService is not available.
| LOGGER.warn("Falling back to account type check for isRootAdmin for account ID: {} as no AccountService bean found: {}", accountId, e.getMessage()); | |
| Account caller = getCallingAccount(); | |
| return caller != null && caller.getType() == Account.Type.ADMIN; | |
| throw new CloudRuntimeException("AccountService bean not found, cannot determine if calling account is root admin for account ID: " + accountId, e); |
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
|
@blueorangutan package |
|
@shwstppr a [SL] Jenkins job has been kicked to build packages. It will be bundled with no SystemVM templates. I'll keep you posted as I make progress. |
|
@shwstppr should we backport this to 4.20? |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 16650 |
@DaanHoogland we can base it for 4.20 as it would also prevent future forward merge conflicts. But I was a bit concerned about breaking something. I'll check and run some tests. I guess it would need more diligent testing if it goes into 4.20.3 |
Ya, I am a bit apprehensive about merging this to 4.20.3 late in the release cycle. |
I understand @Abhisar , But then I would like to mark it for 20.4 . This should really go in as old a release as possible |
Description
AccountService.isRootAdmin(Long)is currently invoked each time to check if an account or caller is a root admin, leading to repeated DB lookups. In most cases, the Account object is already available and should be used directly. For the caller, the root admin flag is now cached in CallContext to avoid repeated evaluations.Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
Without change, 80 calls for AccountDaoImpl.findById during deploy VM and it took 4.994s in a local simulator env,
After the change, AccountDaoImpl.findById calls reduced to 45 during deploy VM, and it took 3.082s in a local simulator env,
The considerable time difference (0m4.994s vs 0m3.082s) could be intermittent and may need more testing/profiling. Reduction in DB queries is certainly real.
How did you try to break this feature and the system with this change?