Open Closed

About background workers to run at the same time in Hangfire and the dbcontext problem. #6617


User avatar
0
user5.abpio created

Hello there

We know that there is a problem with the dbcontext class running concurrently in the same scope.

In Hangfire, if different background workers run at the same time, will there be a concurrency problem when recording data related to dbcontext? How is it safe to use multiple dbcontexts in ABP.IO in Hangfire at the same time?

I am attaching below the working code in a sample worker (DoWorkAsync method in HangfireBackgroundWorkerBase class). Is it ok if all my worker classes work like this?

  • ABP Framework version: v7.4.2
  • UI Type: Angular
  • Database System: EF Core ( PostgreSQL) /
  • Tiered (for MVC) or Auth Server Separated (for Angular): yes/no
  • Exception message and full stack trace:
  • Steps to reproduce the issue:

11 Answer(s)
  • User Avatar
    0
    liangshiwei created
    Support Team Fullstack Developer

    In Hangfire, if different background workers run at the same time, will there be a concurrency problem when recording data related to dbcontext?

    If they operate on the same data record, there may be concurrency.

    You can consider using Distributed Locking: https://docs.abp.io/en/abp/latest/Distributed-Locking

  • User Avatar
    0
    user5.abpio created

    As far as I understand, a redis db is added for lock tracking and the locking handle of the methods of the requested services is used.

    I have a postgresql database and I have a project. Inside there are different workers using the same dbcontext. If you interpret the code in the picture, would it be safer to have the unitofwork block outside the scope block or inside the scope block to avoid concurrency issues or injecting a new instance of dbcontext into the manager classes?

  • User Avatar
    0
    liangshiwei created
    Support Team Fullstack Developer

    Hi,

    would it be safer to have the unitofwork block outside the scope block or inside the scope block to avoid concurrency issues or injecting a new instance of dbcontext into the manager classes

    I guess it won't avoid concurrency.

    When multiple workers operate on the same data record at the same time, concurrency problems may occur

    There is documentation on concurrency control here: https://docs.abp.io/en/abp/latest/Concurrency-Check

  • User Avatar
    0
    user5.abpio created

    First of all, thank you for your answers.

    To avoid this type of conflict in .NET forms, it is recommended to create different instances of dbcontext. It is said that there may be a concurrency problem with the same dbcontext.

    If you have an abp.io project and you are using hangfire background workers that use dbcontext (maybe with different tables), what kind of coding would you do ? Is there an example ? How can I provide this safely in the hangfire module in ABP.IO ?

  • User Avatar
    0
    liangshiwei created
    Support Team Fullstack Developer

    Hi,

    Sorry, Actually I don't quite understand what you mean.

    Concurrency has nothing to do with context instances. This is the explanation of concurrency:

    In most scenarios, databases are used concurrently by multiple application instances, each performing modifications to data independently of each other. When the same data gets modified at the same time, inconsistencies and data corruption can occur, e.g. when two clients modify different columns in the same row which are related in some way. This page discusses mechanisms for ensuring that your data stays consistent in the face of such concurrent changes.

    See: https://learn.microsoft.com/en-us/ef/core/saving/concurrency?tabs=data-annotations

    If you have an abp.io project and you are using hangfire background workers that use dbcontext (maybe with different tables), what kind of coding would you do ? Is there an example ? How can I provide this safely in the hangfire module in ABP.IO ?

    Sorry, no such example, you usually don't need to know about the context instance. You need to control concurrency: https://docs.abp.io/en/abp/latest/Concurrency-Check

  • User Avatar
    0
    liangshiwei created
    Support Team Fullstack Developer

    If I misunderstand something, please let me know.

  • User Avatar
    0
    user5.abpio created

    I want to learn that if I run one more background worker of hangfire in ABP.IO and create new Scope instance there. If I create my UnitOfWorkManager and DomainService instances from that scope, can I avoid dbcontext concurrency conflict?

  • User Avatar
    0
    liangshiwei created
    Support Team Fullstack Developer

    Hi,

    No, I don't think it avoids concurrency conflict.

    As I said: https://support.abp.io/QA/Questions/6617/About-background-workers-to-run-at-the-same-time-in-Hangfire-and-the-dbcontext-problem#answer-3a108f37-6ca9-8b3b-f9d1-aec4b6e66687

  • User Avatar
    0
    liangshiwei created
    Support Team Fullstack Developer

    Another explanation, hope it helps you understand concurrency

    https://stackoverflow.com/questions/52613620/concurrency-across-a-scoped-dbcontext

  • User Avatar
    0
    user5.abpio created

    I guess I didn't express my request clearly and I apologize for that. I have knowledge about concurrency. If I didn't use abp.io, I would know how to avoid this conflict. I wanted to know how abp.io would behave when multiple hangfire workers are running at the same time, if the dbcontext in the hangfire workers has unitofwork instances created there. I would even like to know how you proceeded if you have dealt with such a development before.

    I guess I will test this and find out.

    Thank you liangshiwei for your attention and help.

  • User Avatar
    0
    liangshiwei created
    Support Team Fullstack Developer

    Hi,

    In ABP we recommend using optimistic concurrency control, you can check the article https://community.abp.io/posts/handle-concurrency-with-ef-core-in-an-abp-framework-project-with-asp.net-core-mvc-jlkc3w8f

Made with ❤️ on ABP v8.2.0-preview Updated on March 25, 2024, 15:11