Before executing a query with pagination and a lot of filters, I call .CountAsync() on it. It turned out that, for some filter conditions, .CountAsync() takes a very long time to finish (because of necessary joins) and the advantage of having the number available is not that important that it is worth the long waiting time.

在执行一个带有分页和大量过滤器的查询之前，我调用.CountAsync（）。事实证明，对于某些过滤器条件，.CountAsync（）需要很长时间才能完成（因为必要的连接），并且拥有可用数量的优势并不重要，值得长时间等待。

Thus I decided to cancel the counting in those scenarios where it takes longer than one second and proceed with the actual query.

因此，我决定取消那些需要超过一秒时间的计数，并继续进行实际的查询。

var tokenSource = new CancellationTokenSource();
var ct = tokenSource.Token;
var totalCountTask = query.CountAsync(ct);
var finishedTask = await Task.WhenAny(totalCountTask, Task.Delay(1000));
var totalCount = 0;

if (finishedTask == totalCountTask)
{
    totalCount = await totalCountTask;
}
else
{
    tokenSource.Cancel();
}

items = await query
                .Skip((filter.Page - 1) * filter.PageSize)
                .Take(filter.PageSize)
                .ToListAsync();

But in cases where the count operation is cancelled, the next query executions throws an exception:

但在取消计数操作的情况下，下一次查询执行会抛出一个异常：

System.InvalidOperationException: 'A second operation was started on this context instance before a previous operation completed. ...

But even though the task is cancelled successfully (I checked this in debug mode), it seems the previous query is still running in the background, preventing DbContext to do other work.

但是，即使任务被成功取消(我在调试模式下检查了这一点)，前面的查询似乎仍然在后台运行，从而阻止DbContext执行其他工作。

Is there any possibility to "free" the DbContext after cancelling a query to be able to use it again?

在取消查询后，是否有可能“释放”DbContext以便能够再次使用它？

After the query is aborted, it need to wait that abort is completed. Else, it's possible the second query start before the abort complete.

查询中止后，需要等待中止完成。否则，第二个查询可能在中止完成之前开始。

if (finishedTask == totalCountTask)
{
    totalCount = await totalCountTask;
}
else
{
    tokenSource.Cancel();
    try
    {
        await totalCountTask;
    }
    catch // swallow the exception from the abort
    { }
}

The explanation is that a cancelled task isn't in a Cancelled state immediately after cancelling the cancellation token.

其解释是，取消的任务在取消令牌后不会立即处于已取消状态。

A cancellation token modestly signals that cancellation is requested, it's in no way capable of effecting cancellation instantly. It's an application programmer's task to make a process listen to the cancelation request. They will always try to stop a process "gracefully". What that means differs per task, but think of disposing IDisposables, closing connections, etc., all aimed at preventing side effects. That will always take some time.

取消令牌只是谦虚地发出取消请求的信号，它根本不能立即取消。应用程序程序员的任务是让进程侦听取消请求。他们总是试图“优雅地”停止一个进程。这意味着每个任务不同，但请考虑处理IDisposable、关闭连接等，所有这些都是为了防止副作用。这总是需要一些时间。

This simplified version of your code is (nearly always) guaranteed to throw the InvalidOperationException. When the commented line is commented out, it won't ever throw, because the task gets the (short) time it needs to abort.

这个简化版本的代码(几乎总是)保证会抛出InvalidOperationException异常。当注释行被注释掉时，它永远不会抛出，因为任务获得了(短的)中止所需的时间。

var query = dbContext.Set<SomeTable>();

var tokenSource = new CancellationTokenSource();
var ct = tokenSource.Token;
var totalCountTask = query.CountAsync(ct);
await Task.WhenAny(totalCountTask, Task.CompletedTask);
tokenSource.Cancel();

//while (!totalCountTask.IsCompleted); // This "fixes" the exception
query.Load();

Needless to say, this is bad code. Normally, it shouldn't be necessary to orchestrate parallel tasks. The fundamental flaw in your case is that a DbContext instance is accessed by multiple threads. That should never ever happen. DbContext is not thread-safe. Each task should have its own context instance.

不用说，这是糟糕的代码。正常情况下，应该没有必要编排并行任务。您的案例中的根本缺陷是DbContext实例被多个线程访问。这永远不应该发生。DbContext不是线程安全的。每个任务都应该有自己的上下文实例。