Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-30748

LOCKing mechanism Improvement Request that milestone of rdbms history



    • Task
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • None
    • None
    • None


      Currently most of dbms imploying that kinda greey logic
      that take the lock for atom. (For example,
      if, there is few hundreds of requests from multiple and concurrent location to
      one single record to insert/update/alter what every concurrent. This situation only allow to get the lock for an user when only luckly reach the record. which mean very randomly can get a lock.) This situation make problem hard to solve.
      So strongly suggest you to improve deadlock problem which go down in history,
      manage lock request as FIFO in order and give the lock in sequence/arrival order.
      Fro example,
      no1. request insert
      no2. request update
      no3. request select!
      no4. request select
      no5. request alter
      no6. request select!
      no7. request delete
      no8. request another alter
      no9. request select!

      each of request will be arraived in the db system in order(sure, system-wise, there is no real concurrent) and must be applied in sequence. Not greedly make rece condition that today's unresolvable problem. The semapore or mutex or whatever lock mechnism will be totally redesigned to beFIFO managed without performance impact.
      It also has to be turn-of/off by config. default off.


        Issue Links



              Unassigned Unassigned
              npdmailing@gmail.com Mitchell Lee
              0 Vote for this issue
              4 Start watching this issue



                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.