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?
Our Angular app.component.ts has code call, but actually now we got a blank header and Abp's default footer. It seems the replacement not working anymore this.replaceableComponents.add({ component: BreadcrumbComponent, key: eThemeLeptonXComponents.Breadcrumb, }); ... this.replaceableComponents.add({ component: AppSettingsComponent, key: eThemeLeptonXComponents.Footer, });
I feel like it is our code base issue, some code hold long transactions
yarn install v1.22.22 info No lockfile found. [1/4] Resolving packages... error Couldn't find package "@abp/ng.components" on the "npm" registry.
package version is ~9.1.1
I did run abp login command first.
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?
Is it possible because of ConcurrencyStamp? For above simple statement, it should not take more than 30 seconds;
After upgrade and deploy the application (EF core, Micro serivce) , the app data access layer throw timeout exception, here is one of example:
(@p6 uniqueidentifier,@p7 nvarchar(40),@p4 nvarchar(40),@p5 datetime2(7))UPDATE [Agents] SET [ConcurrencyStamp] = @p4, [LastModificationTime] = @p5 OUTPUT 1 WHERE [Id] = @p6 AND [ConcurrencyStamp] = @p7
The agents table has 900+ records only. Azure SQL server's compatible level is SQL Server 2019.
