Hi, I am experiencing performance problems when working with requests up to 120 seconds maximum.
The main problem is the blocking of the tables on which I am inserting/updating in the same operation. I am transferring the development team's proposal for improvement: In this process an endpoint of an App Service is called which, in turn, invokes an external service to read information. The theory is that before the UoW (Unit of Work), when synchronising an entity, was managed with the default configuration: on receiving the request, the API opened the UoW and, on completion, it was completed and the changes were automatically saved. What happens? Fetching data from the external API can take tens of seconds for the UoW to complete, which keeps the transaction open and causes crashes in the database (which are most of the errors we are seeing now).
We doubt that this is actually causing these database timeouts, since the database transaction is understood to start and end when SaveChangesAsync is called. We don't know to what extent it makes sense that, when starting a transactional Unit of Work, these table locks occur.
https://abp.io/community/articles/understanding-transactions-in-abp-unit-of-work-0r248xsr#gsc.tab=0
2 Answer(s)
-
0
In ABP, when a transactional Unit of Work (UoW) is started (the default for non-GET requests), a database transaction is opened at the beginning of the request and remains open until the UoW is completed (typically at the end of the request or when CompleteAsync is called). This means that if you perform long-running operations (such as calling external APIs) inside the UoW, the transaction and any associated table locks will be held for the entire duration, potentially causing blocking and timeouts in the database.
The transaction is not only held during SaveChangesAsync; it is held for the entire lifetime of the UoW. SaveChangesAsync persists changes to the database, but the transaction is only committed when CompleteAsync is called. If the UoW is open while waiting for external services, the transaction remains open, and locks may be held, leading to performance issues and blocking.
To avoid this, you should minimize the time a transaction is held. One recommended approach is to perform external API calls and other long-running operations outside the transactional UoW. Only wrap the actual database operations in a short-lived UoW/transaction. For example:
// Fetch data from external API (outside UoW) var externalData = await externalService.GetDataAsync(); // Start UoW only for DB operations using (var uow = _unitOfWorkManager.Begin(isTransactional: true)) { // Insert/update entities await _repository.UpdateAsync(...); await uow.CompleteAsync(); }- This pattern ensures that the transaction is held only for the minimal time required to perform database operations, reducing the risk of table locks and timeouts.
Sources:
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
-
0
The unit of work creates a scoped transaction to ensure the consistency of operations within the entire unit of work.
The
isTransactional: trueis forPOST/PUT/DELETErequests, and itsfalseforGETrequests.EFCoreDBContext.Database.BeginTransactionAsync()https://learn.microsoft.com/en-us/ef/core/saving/transactions
The
IsolationLevelis based on your database server. https://learn.microsoft.com/en-us/dotnet/api/system.transactions.isolationlevel?view=net-9.0Thanks.
