Uploaded image for project: 'phpBB3'
  1. phpBB3
  2. PHPBB3-9685

Unable to create "Fulltext native" search index using the mssqlnative DBAL

    Details

    • Type: Bug
    • Status: Unverified Fix
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 3.0.7-PL1
    • Fix Version/s: 3.0.9-RC1
    • Labels:
      None
    • Environment:

      Description

      Attempting to create "Fulltext native" search index from "ACP" -> "Maintenance" -> "Database" -> "Search index" generates the following error:

      SQL ERROR [ mssqlnative ]

      SQLSTATE: 42000 code: 3988 message: [Microsoft][SQL Server Native Client 10.0][SQL Server]New transaction is not allowed because there are other threads running in the session. [3988]

      BACKTRACE

      FILE: includes/db/dbal.php
      LINE: 264
      CALL: dbal->sql_error()

      FILE: includes/search/fulltext_native.php
      LINE: 1190
      CALL: dbal->sql_transaction()

      FILE: includes/acp/acp_search.php
      LINE: 401
      CALL: fulltext_native->index()

      FILE: includes/acp/acp_search.php
      LINE: 46
      CALL: acp_search->index()

      FILE: includes/functions_module.php
      LINE: 507
      CALL: acp_search->main()

      FILE: adm/index.php
      LINE: 74
      CALL: p_master->load_active()

        Activity

        Hide
        naderman Nils Adermann added a comment -

        Unfortunately I am unable to reproduce this on my local setup. I assume it is either related to the data you have in your tables or more likely something related to your system configuration. I suggest you ask on the support forums if you continue to run into this error or supply with more information on how to reproduce this problem.

        Show
        naderman Nils Adermann added a comment - Unfortunately I am unable to reproduce this on my local setup. I assume it is either related to the data you have in your tables or more likely something related to your system configuration. I suggest you ask on the support forums if you continue to run into this error or supply with more information on how to reproduce this problem.
        Hide
        Indiana Krom Indiana Krom [X] (Inactive) added a comment -

        To reproduce this bug you must be using mssqlnative to connect to the database server. mssql_odbc or mssql (via FreeTDS) will not reproduce this bug.

        Show
        Indiana Krom Indiana Krom [X] (Inactive) added a comment - To reproduce this bug you must be using mssqlnative to connect to the database server. mssql_odbc or mssql (via FreeTDS) will not reproduce this bug.
        Hide
        Oleg Oleg [X] (Inactive) added a comment - - edited

        Looks like a legitimate issue:

        http://stackoverflow.com/questions/2568580/issues-with-linq-to-entity-adding-records
        http://stackoverflow.com/questions/2113498/sqlexception-from-entity-framework-new-transaction-is-not-allowed-because-there

        (19:15:53) nn-: if you can reproduce it obtain a backtrace at the point where it dies
        (19:16:12) nn-: according to these questions you should find yourself in a loop iterating over query results

        (19:17:44) nn-: ah, ticket already has a backtrace
        (19:19:03) nn-: line 401 of acp_search
        (19:19:10) nn-: is inside such a loop
        (19:20:18) nn-: the second stackoverflow link provides a workaround
        (19:20:29) nn-: basically both retrieve and save data in chunks
        (19:21:20) nn-: the loop in our case is over posts, thus is expected to operate on large amount of data
        (19:21:33) nn-: on the other hand it looks like acp_search already has a provision for chunking
        (19:23:03) nn-: the solution would be to buffer posts around line 401 in acp_search
        (19:23:27) nn-: should be conditional on engine == mssqlnative
        (19:23:48) nn-: this will obviously require additional memory, the tradeoff appears to be inevitable

        (19:31:32) Noxwizard: The MARS suggestion I saw awhile back doesn't fix it either.
        (19:31:53) nn-: what's mars again?
        (19:32:14) Noxwizard: Multiple Active Result Sets
        (19:32:43) nn-: might have something to do with transactions like the title claims
        (19:33:03) nn-: e.g. phpbb opening them implicitly even for selects
        (19:33:41) nn-: maybe you need to run an explicit transaction around everything
        (19:34:02) nn-: maybe post indexer does a transaction inside the outer fetch loop

        Show
        Oleg Oleg [X] (Inactive) added a comment - - edited Looks like a legitimate issue: http://stackoverflow.com/questions/2568580/issues-with-linq-to-entity-adding-records http://stackoverflow.com/questions/2113498/sqlexception-from-entity-framework-new-transaction-is-not-allowed-because-there (19:15:53) nn-: if you can reproduce it obtain a backtrace at the point where it dies (19:16:12) nn-: according to these questions you should find yourself in a loop iterating over query results (19:17:44) nn-: ah, ticket already has a backtrace (19:19:03) nn-: line 401 of acp_search (19:19:10) nn-: is inside such a loop (19:20:18) nn-: the second stackoverflow link provides a workaround (19:20:29) nn-: basically both retrieve and save data in chunks (19:21:20) nn-: the loop in our case is over posts, thus is expected to operate on large amount of data (19:21:33) nn-: on the other hand it looks like acp_search already has a provision for chunking (19:23:03) nn-: the solution would be to buffer posts around line 401 in acp_search (19:23:27) nn-: should be conditional on engine == mssqlnative (19:23:48) nn-: this will obviously require additional memory, the tradeoff appears to be inevitable (19:31:32) Noxwizard: The MARS suggestion I saw awhile back doesn't fix it either. (19:31:53) nn-: what's mars again? (19:32:14) Noxwizard: Multiple Active Result Sets (19:32:43) nn-: might have something to do with transactions like the title claims (19:33:03) nn-: e.g. phpbb opening them implicitly even for selects (19:33:41) nn-: maybe you need to run an explicit transaction around everything (19:34:02) nn-: maybe post indexer does a transaction inside the outer fetch loop
        Hide
        Noxwizard Patrick Webster added a comment -

        Reopening until we can find a way to address this.

        Show
        Noxwizard Patrick Webster added a comment - Reopening until we can find a way to address this.
        Hide
        naderman Nils Adermann added a comment -

        Ok, managed to reproduce this myself. I think the issue was that I never had enough posts in my database to notice this when I was testing it before.

        Show
        naderman Nils Adermann added a comment - Ok, managed to reproduce this myself. I think the issue was that I never had enough posts in my database to notice this when I was testing it before.
        Hide
        bantu Andreas Fischer added a comment -

        I've got to take this back. $i is not defined.

        php -r "var_dump(\$i++, \$i++);"
        PHP Notice:  Undefined variable: i in Command line code on line 1
        PHP Stack trace:
        PHP   1. {main}() Command line code:0
        NULL
        int(1)
        

        Show
        bantu Andreas Fischer added a comment - I've got to take this back. $i is not defined. php -r "var_dump(\$i++, \$i++);" PHP Notice: Undefined variable: i in Command line code on line 1 PHP Stack trace: PHP 1. {main}() Command line code:0 NULL int(1)
        Show
        naderman Nils Adermann added a comment - https://github.com/naderman/phpbb3/commit/91b319525546ea696653dbb7f2c494058a85b00b#commitcomment-306263

          People

          • Assignee:
            naderman Nils Adermann
            Reporter:
            kolthor kolthor
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development