Uploaded image for project: 'MariaDB Connector/Python'
  1. MariaDB Connector/Python
  2. CONPY-304

threads isolation on pool

Details

    • Bug
    • Status: Closed (View Workflow)
    • Critical
    • Resolution: Not a Bug
    • 1.1.10
    • N/A
    • Connection Pooling
    • Python 3.11.2

    Description

      • for each worker, and instance of my webapp is created.
      • each instance create a pool (mariadb.ConnectionPool) named 'poolName_' + worker.pid, on the same DB with the same user.

      worker1 > pool1 >>- connections 1,2,3,4,5,6,7,8,9,10
      worker2 > pool2 >>- connections 11,12,13,14,15,16,17,18,19,20
      worker3 > pool3 >>- connections 21,22,23,24,25,26,27,28,29,30

      so worker1 calling pool1.get-connection should return only connections 1,2,3,4,5,6,7,8,9,10

      When looking to my logs i can see that :

      1/ calling dbpool.get_connection() return an connection from other pool!!
      worker2 > pool2 >>- connections 1,3,8,12,21,22,15
      worker3 > pool3 >>- connections 2,3,12,25
      ccl: pools share connections

      2/pool object are used by different workers (you can say its a flask pb)
      worker2 > pool2
      worker3 > pool2
      ccl: workers share pools

      Is it a bug or a feature?
      is it a problem for production use?

      Attachments

        Activity

          Ascending order - Click to sort in descending order
          soFTCure emmanuel bestagno added a comment -

          Hi Georg, if you need more precisions don't hesitate...

          soFTCure emmanuel bestagno added a comment - Hi Georg, if you need more precisions don't hesitate...
          soFTCure emmanuel bestagno added a comment -

          hi,
          was checking again and add "SELECT CONNECTION_ID()" in my logs...
          Now , i can see that this CONNECTION_ID()" is linked to only one worker/dbpool tuple.

          The python id() tips can use the same value between process/thread, that the reason..

          sorry, i think you can close this issue;

          logs with connection_id data:
          ->Create_dbpool worker: 3860686 id=(139653109612368) name= poolName_3860686 size=6 user=webappdev host=localhost
          ->(139653109612368) #connections in connection pool:6 maxsize 64 name= poolName_3860686 size=6
          get_db_cnx_from_pool CREATE DBPOOL: worker: 3860686 dbpool: (139653109612368) name poolName_3860686
          get_db_cnx_from_pool NEXCNX : worker: 3860686 dbpool: (139653109612368) name poolName_3860686 Newcnx: (139653108979408) localhost
          Current session's process ID: 27634 139653108979408
          Poolcnx(teardown):db.close()139653108979408[f3d6d0>]
          set_cached 10 Lucsemb
          ->Create_dbpool worker: 3860685 id=(139653109595536) name= poolName_3860685 size=6 user=webappdev host=localhost
          ->(139653109595536) #connections in connection pool:6 maxsize 64 name= poolName_3860685 size=6
          get_db_cnx_from_pool CREATE DBPOOL: worker: 3860685 dbpool: (139653109595536) name poolName_3860685
          get_db_cnx_from_pool NEXCNX : worker: 3860685 dbpool: (139653109595536) name poolName_3860685 Newcnx: (139653108979408) localhost
          Current session's process ID: 27640 139653108979408
          Poolcnx(teardown):db.close()139653108979408[f3d6d0>]

          soFTCure emmanuel bestagno added a comment - hi, was checking again and add "SELECT CONNECTION_ID()" in my logs... Now , i can see that this CONNECTION_ID()" is linked to only one worker/dbpool tuple. The python id() tips can use the same value between process/thread, that the reason.. sorry, i think you can close this issue; logs with connection_id data: ->Create_dbpool worker: 3860686 id=(139653109612368) name= poolName_3860686 size=6 user=webappdev host=localhost ->(139653109612368) #connections in connection pool:6 maxsize 64 name= poolName_3860686 size=6 get_db_cnx_from_pool CREATE DBPOOL: worker: 3860686 dbpool: (139653109612368) name poolName_3860686 get_db_cnx_from_pool NEXCNX : worker: 3860686 dbpool: (139653109612368) name poolName_3860686 Newcnx: (139653108979408) localhost Current session's process ID: 27634 139653108979408 Poolcnx(teardown):db.close()139653108979408 [f3d6d0>] set_cached 10 Lucsemb ->Create_dbpool worker: 3860685 id=(139653109595536) name= poolName_3860685 size=6 user=webappdev host=localhost ->(139653109595536) #connections in connection pool:6 maxsize 64 name= poolName_3860685 size=6 get_db_cnx_from_pool CREATE DBPOOL: worker: 3860685 dbpool: (139653109595536) name poolName_3860685 get_db_cnx_from_pool NEXCNX : worker: 3860685 dbpool: (139653109595536) name poolName_3860685 Newcnx: (139653108979408) localhost Current session's process ID: 27640 139653108979408 Poolcnx(teardown):db.close()139653108979408 [f3d6d0>]
          soFTCure emmanuel bestagno added a comment -

          I just want to says that MariaDb works fine, robust and realy fast!!!
          Thk, see you in mariaDN day in Brussel...

          soFTCure emmanuel bestagno added a comment - I just want to says that MariaDb works fine, robust and realy fast!!! Thk, see you in mariaDN day in Brussel...
          georg Georg Richter added a comment -

          Issue closed as "not a bug" (as requested by Emmanuel)

          georg Georg Richter added a comment - Issue closed as "not a bug" (as requested by Emmanuel)

          People

            georg Georg Richter
            soFTCure emmanuel bestagno
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

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