Details

    • Type: Bug Bug
    • Status: Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.2.1
    • Fix Version/s: None
    • Component/s: Connection
    • Labels:
      None
    • Environment:
      PHP 5.3.1

      Description

      When you doing a big loop of insertion you have a "too many open cursor".
      The problem is in Doctrine_Connection class
      At line 1005 you should replace :
      $stmt = $this->prepare($query);
      by
      $stmt = $this->dbh->prepare($query);

      and at line 1041 you should replace :
      $stmt = $this->prepare($query);
      by
      $stmt = $this->dbh->prepare($query);

      After this correction, you never have the problem "too many open cursor"

      Thanks to Ota to point that on google groups.
      http://groups.google.com/group/doctrine-user/browse_thread/thread/fe6cd03c8fb18b64/728ec1b4e42b1f0b?lnk=gst&q=doctrine_oracle_adapter#728ec1b4e42b1f0b

        Activity

        Hide
        Jonathan H. Wage added a comment -

        Hmm. This change is invalid because it then doesn't return the proper statement object. What is the real issue we get the too many cursors open error?

        Show
        Jonathan H. Wage added a comment - Hmm. This change is invalid because it then doesn't return the proper statement object. What is the real issue we get the too many cursors open error?
        Hide
        oxman added a comment -

        Why ?
        The both return Doctrine_Adapter_Statement_Interface

        Show
        oxman added a comment - Why ? The both return Doctrine_Adapter_Statement_Interface
        Hide
        Jonathan H. Wage added a comment -

        The change makes it so they return PDOStatement, and we need it to return the Doctrine statement wrapper, right?

        Show
        Jonathan H. Wage added a comment - The change makes it so they return PDOStatement, and we need it to return the Doctrine statement wrapper, right?
        Hide
        oxman added a comment -

        It seems not.

        At line 1005 in Doctrine/Connection.php :
        $stmt = $this->dbh->prepare($query);
        var_dump(get_class($stmt));
        die;

        I see :
        string(33) "Doctrine_Adapter_Statement_Oracle"

        And with :
        $stmt = $this->prepare($query);
        var_dump(get_class($stmt));
        die;

        I see :
        string(29) "Doctrine_Connection_Statement"

        The both implements Doctrine_Adapter_Statement_Interface

        Show
        oxman added a comment - It seems not. At line 1005 in Doctrine/Connection.php : $stmt = $this->dbh->prepare($query); var_dump(get_class($stmt)); die; I see : string(33) "Doctrine_Adapter_Statement_Oracle" And with : $stmt = $this->prepare($query); var_dump(get_class($stmt)); die; I see : string(29) "Doctrine_Connection_Statement" The both implements Doctrine_Adapter_Statement_Interface
        Hide
        vincent added a comment -

        I have this problem in Symfony 1.4.3 when I use comand:
        symfony doctrine:data-load

        I have 3000 - 4000 lines in my fixtures and max open cursor at 300 on my database oracle.

        This problem can an issue???

        Show
        vincent added a comment - I have this problem in Symfony 1.4.3 when I use comand: symfony doctrine:data-load I have 3000 - 4000 lines in my fixtures and max open cursor at 300 on my database oracle. This problem can an issue???
        Hide
        Jonathan H. Wage added a comment -

        I see, well the change still is not right because it bypasses all the logic in Doctrine_Connection::prepare() which is for sure required and can't just be removed. We need to determine the real issue here in order to properly patch it.

        Show
        Jonathan H. Wage added a comment - I see, well the change still is not right because it bypasses all the logic in Doctrine_Connection::prepare() which is for sure required and can't just be removed. We need to determine the real issue here in order to properly patch it.
        Hide
        Peter Wooster added a comment -

        I'm encountering the same ORA-1000 problem running the symfony doctrine:build-schema command. We are still using PDO, but I have asked in the users group if that's the best choice. The problem is that the listTableColumns and listTableRelations methods both leave a cursor open. They both call Connection::fetchAssoc, so they should be reading all the records.

        I narrowed it down a little:

        This works properly when no parameters are provided:

        $sql = "SELECT * FROM all_tab_columns tc WHERE tc.table_name = 'DEAL'";
        $result = $connection->fetchAssoc($sql, array());

        This doesn't release the cursor when a named parameter is provided

        $sql = "SELECT * FROM all_tab_columns tc WHERE tc.table_name = :tn";
        $result = $connection->fetchAssoc($sql, array(':tn' => 'DEAL')); // doesn't release cursor

        This doesn't release the cursor when a positional parameter is provided

        $sql = "SELECT * FROM all_tab_columns tc WHERE tc.table_name = ?";
        $result = $connection->fetchAssoc($sql, array('DEAL')); // doesn't release cursor

        This works properly when the PDO connection is used directly

        $sql = "SELECT * FROM all_tab_columns tc WHERE tc.table_name = :tn";
        $dbh = $connection->getDbh();
        $stmt = $dbh->prepare($sql);
        $stmt->execute(array(':tn' => 'DEAL'));
        $result = $stmt->fetchAll();

        Show
        Peter Wooster added a comment - I'm encountering the same ORA-1000 problem running the symfony doctrine:build-schema command. We are still using PDO, but I have asked in the users group if that's the best choice. The problem is that the listTableColumns and listTableRelations methods both leave a cursor open. They both call Connection::fetchAssoc, so they should be reading all the records. I narrowed it down a little: This works properly when no parameters are provided: $sql = "SELECT * FROM all_tab_columns tc WHERE tc.table_name = 'DEAL'"; $result = $connection->fetchAssoc($sql, array()); This doesn't release the cursor when a named parameter is provided $sql = "SELECT * FROM all_tab_columns tc WHERE tc.table_name = :tn"; $result = $connection->fetchAssoc($sql, array(':tn' => 'DEAL')); // doesn't release cursor This doesn't release the cursor when a positional parameter is provided $sql = "SELECT * FROM all_tab_columns tc WHERE tc.table_name = ?"; $result = $connection->fetchAssoc($sql, array('DEAL')); // doesn't release cursor This works properly when the PDO connection is used directly $sql = "SELECT * FROM all_tab_columns tc WHERE tc.table_name = :tn"; $dbh = $connection->getDbh(); $stmt = $dbh->prepare($sql); $stmt->execute(array(':tn' => 'DEAL')); $result = $stmt->fetchAll();
        Hide
        Clément Herreman added a comment -

        As I went through this bug, I looked for a fix. I found one here https://github.com/derflocki/doctrine1/commit/47b926a523f9f6e3b88042ef2939af0646285ea2

        Basically it consist of freeing cursors that aren't used by a SELECT query, thus preventing Oracle from throwing an exception on batch insert/delete.

        Show
        Clément Herreman added a comment - As I went through this bug, I looked for a fix. I found one here https://github.com/derflocki/doctrine1/commit/47b926a523f9f6e3b88042ef2939af0646285ea2 Basically it consist of freeing cursors that aren't used by a SELECT query, thus preventing Oracle from throwing an exception on batch insert/delete.

          People

          • Assignee:
            Jonathan H. Wage
            Reporter:
            oxman
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: