How does the Uow work ?

[John0King]

it seems that UowMiddleware create a root UOW, and create ChildUnitOfWork when you calling into _uowManagerr.Begin() .

and that will cause slow trancation commit if you are doing slow async work inside controller action.

I'm I right ?

[realLiangshiwei]

If your method takes a long time to execute, then the transaction time will be extended.

More information you can check the document: https://docs.abp.io/en/abp/latest/Unit-Of-Work

[John0King]

[HttpPost]
public async Task<Result> Foo()  // MVC action method
{
   using(var uow = _uowManager.Begin())    // my undestand is  this uow is not the root uow but a child  uow
  {
     await  updateRowAsLock();
     await uow.SaveChanges();
      await  do20msWork();
      await  uow.CompleteAsync();  // so this won't commit the transaction ,
  }
    await do20000msWork();   // so this 2 second work will block other  query  if the query try to get the  `updateRowAsLock()`'s  row

}

and the uow is complete when middleweare pipline complete

// the uow middleware
public Task InvokeAsync(HttpContext httpContext)
{ 
  using(var uow = _uowManager.Reserve()
  {
     await _next();   //  this is our mvc request 
      await uow.ComplateAsync(httpContext.RequestAbort);  // this may cause our transication fail, if user disconnect the connection
   }
}

Does my understand right ?

[John0King]

and IMO it shoudn't be the root uow in middlware (eg. the begin of the request ),
the unitOfWork should start when user begin the unitOfWork via UnitOfWorkManager or UnitOfWorkAttribute,

[realLiangshiwei]

https://docs.abp.io/en/abp/latest/Unit-Of-Work#begin-a-new-unit-of-work

requiresNew (bool): Set true to ignore the surrounding unit of work and start a new UOW with the provided options. Default value is false. If it is false and there is a surrounding UOW, Begin method doesn't actually begin a new UOW, but silently participates to the existing UOW.

and IMO it shoudn't be the root uow in middlware (eg. the begin of the request ),....

This is the default design, you can remove app.UseUnitOfWork(); in your project.

You also can disable it if you want:https://docs.abp.io/en/abp/latest/Unit-Of-Work#default-options

[zhutoutou]

There are some errors in your description. The database transaction being when your first operation in repo. you can see below picture. we can find transaction will start in first operation and end in your manual explicit commit or service handle completely.

[John0King]

I'm sorry that I'm not understand your "commit transaction if manual explicit commit"

abp/framework/src/Volo.Abp.Uow/Volo/Abp/Uow/UnitOfWorkManager.cs

Lines 26 to 39 in f17dfdc

	public IUnitOfWork Begin(AbpUnitOfWorkOptions options, bool requiresNew = false)
	{
	Check.NotNull(options, nameof(options));
	var currentUow = Current;
	if (currentUow != null && !requiresNew)
	{
	return new ChildUnitOfWork(currentUow);
	}
	var unitOfWork = CreateNewUnitOfWork();
	unitOfWork.Initialize(options);
	return unitOfWork;

abp/framework/src/Volo.Abp.Uow/Volo/Abp/Uow/ChildUnitOfWork.cs

Lines 64 to 67 in f17dfdc

	public Task CompleteAsync(CancellationToken cancellationToken = default)
	{
	return Task.CompletedTask;
	}

[zhutoutou]

The big picture aims to tell the lifetime of a unit of work. It doesn't begin transaction in middleware.

I'm sorry that I'm not understand your "commit transaction if manual explicit commit"
The explicit commit means manual beginning a transaction with explicit commit, such like below in ABP document. you can control your transaction scope precisely.

[John0King]

@realLiangshiwei @zhutoutou
I'm also confused with multiple DbContext with multiple Database instance, eg. a database named "DbA" on "192.168.1.100" and another database named "DbB" on "192.168.1.101".

from here

abp/framework/src/Volo.Abp.Uow/Volo/Abp/Uow/UnitOfWork.cs

Lines 366 to 372 in f17dfdc

	protected virtual async Task CommitTransactionsAsync()
	{
	foreach (var transaction in GetAllActiveTransactionApis())
	{
	await transaction.CommitAsync();
	}
	}

it seems that it may cause the unitofwork not distrubted trancational , and one might sucess and one might fail(may because network problem or the power supplier lose energy)

do I miss something ?

[zhutoutou]

You are right, the distributed transaction may need be imported by yourself. you can try override CommitTransactionsAsync method with distributed transaction implement. It should be a complex problem.

[John0King]

@zhutoutou @realLiangshiwei
I'm "copy" the abps's unitofwork to a old project , and now I'm confused about the Uow ,
the DbContextProvider is asking for a existing UnitOfWord exists, and I know that unitofwork middleware is reseverd one , but that's actually begin a reverd uow for every request, but what about other scenario like the IBackgroundWork ? since is doesn't begin or reserve a unitofwork, does that means that it will throw when you calling into the IRepository ？