when a method has [UnitOfWork], should it call unit of work complete automatically by ABP?
still the same.
my app.config.ts
provideRouter(APP_ROUTES), APP_ROUTE_PROVIDER, provideSideMenuLayout(), provideThemeLeptonX(), OVERRIDE_LEPTON_X_USER_MENU_PROVIDERS, FOOTER_PROVIDER,
Somehow I made it working. It might because the upgraded component still depends some shared module? Not quite sure (too much code changes). I change it anyway.
Now I am trying to customize the menu items when click the profile icon on top right corner, but click it nothing happens: import { NAVIGATE_TO_MANAGE_PROFILE } from '@abp/ng.core'; import { UserMenuService } from '@abp/ng.theme.shared'; import { inject, provideAppInitializer } from '@angular/core'; import { Router } from '@angular/router'; import { eUserMenuItems } from '@volosoft/abp.ng.theme.lepton-x';
// This provider overwrites the right-side user menu when clicking the user profile icon. // ABP 10: The toolbar replacement via replaceableComponents breaks LeptonX rendering, // so we use this approach instead. export const OVERRIDE_LEPTON_X_USER_MENU_PROVIDERS = [ provideAppInitializer(() => { configureUserMenu(); }), ];
function configureUserMenu() { const userMenu = inject(UserMenuService); const router = inject(Router);
const navigateToManageProfile = inject(NAVIGATE_TO_MANAGE_PROFILE); return () => { userMenu.removeItem(eUserMenuItems.LinkedAccounts); userMenu.removeItem(eUserMenuItems.SecurityLogs); userMenu.removeItem(eUserMenuItems.AuthorityDelegation); //userMenu.removeItem(eUserMenuItems.Logout); userMenu.removeItem(eUserMenuItems.MyAccount); userMenu.removeItem(eUserMenuItems.ExternalLogins); userMenu.removeItem(eUserMenuItems.Sessions);
userMenu.addItems([
{
id: eUserMenuItems.MyAccount,
order: 100,
textTemplate: {
icon: 'bi bi-sliders',
text: 'AbpAccount::MyAccount',
},
action: () => router.navigate(['/account/manage'])
//action: () => navigateToManageProfile(),
}
]);
};
}
And in app.config.ts add OVERRIDE_LEPTON_X_USER_MENU_PROVIDERS, to providers list;
what about code like this, would it be a is transaction true? would the Unit of work complete gracefully or roll back properly when there is exception? [UnitOfWork] public async Task Create30DaysReminderAsync(Guid fileId) { try { some Db operations; await CurrentUnitOfWork.SaveChangesAsync(); } catch { throw; } }
what about code like this style: using unit of work
some db operations try { some other db operations } catch { swallow the exception } other db operations unit of work complete
I think it might be our code base issue, though it kind of working in ABP 8, but now with ABP 10 we see quite more chances of Zombie transactions session from SQL server, I do find some code using a unit of work, and call await uow.SaveChangesAsync(); without call await uow.CompleteAsync(); Is it the cause? With ABP 10 has unit of work enhancement?
I feel like it is our code base issue, some code hold long transactions
AI gives this hint, we will check if this is the reason of it: In EF Core 8 and earlier, when you called SaveChangesAsync(), it would generate and execute SQL statements one at a time:
In EF Core 9, it introduced command batching — multiple statements are combined into a single SET NOCOUNT ON; ... batch sent to SQL Server in one round trip:
In EF Core 8, even if a transaction leaked, the individual autoSave commits had already released locks progressively. With EF Core 9 batching, all the locks are held simultaneously until the entire batch completes — so a leaked transaction holds locks on Clients + Documents + DocumentVersions + Files all at once, for the entire duration.
I notice in an AppService Get method, it has code call repository update method too, I remember ABP automatically add unit of work to App Service public methods, does it apply to get method too?