Derby
  1. Derby
  2. DERBY-2639

Bulk data load utility should indicate when it is finished.

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 10.2.2.0
    • Fix Version/s: None
    • Component/s: Store
    • Environment:
      Java Version: 1.5.0_06
      Java Vendor: Sun Microsystems Inc.
      OS name: Windows XP
      IDE: Eclipse
      Derby: 10.2.2, running Embedded

    • Urgency:
      Normal

      Description

      The bulk load CALL SYSCS_UTIL.SYSCS_IMPORT_DATA appears to be finished (i.e. the statement returns), but it is not entirely
      finishing before I try to query the table it is populating. I would expect to get a locking exception, or something of that nature, but
      the error I get is either SQLERROR XSCB1 or SQLERROR XSCBH1, Container <containerName> not found. It has given me both at different times.

      An improvement I would suggest is having SYSCS_UTIL.SYSCS_IMPORT_DATA indicate when it is done loading. As it stands now, the thread I have running it finishes before the utility finishes, and I have no elegant way of knowing when the load is done, other than trying to use the table and trapping for I listed above.

      For more information, please see the post "SQL Exception: Container xxx not found" in derby-user mail list.

      1. crashderby_src.zip
        7 kB
        Carl-Erik Kopseng
      2. DerbyProblem.jar
        57 kB
        Patty Parker

        Activity

        Hide
        Mike Matrigali added a comment -

        triaged for 10.8.

        Show
        Mike Matrigali added a comment - triaged for 10.8.
        Hide
        Carl-Erik Kopseng added a comment -

        @Knut Anders Hatlen
        You are indeed right, Knut, as that explains the errors as well as fixes them. I never thought I would be so glad to be proven wrong! I falsely assumed the con.close() would do what <code>DriverManager.getConnection("jdbc:derby:testdb;shutdown=true"); </code> does, but I was obviously mistaken. Maybe this will come in handy for someone else someday.

        Tusen takk

        Show
        Carl-Erik Kopseng added a comment - @Knut Anders Hatlen You are indeed right, Knut, as that explains the errors as well as fixes them. I never thought I would be so glad to be proven wrong! I falsely assumed the con.close() would do what <code>DriverManager.getConnection("jdbc:derby:testdb;shutdown=true"); </code> does, but I was obviously mistaken. Maybe this will come in handy for someone else someday. Tusen takk
        Hide
        Knut Anders Hatlen added a comment -

        Thanks for providing the repro, Carl-Erik. I may be misunderstanding something, but here's what it seems to do:

        Repeat 4 times:

        1) Delete the directory testdb

        2) Connect to the database testdb, create if it doesn't exist

        3) create tables

        4) drop tables

        5) commit

        I don't think this is valid usage, since the second iteration will delete a database that's currently booted. When you reconnect, you won't create a new database, but instead connect to the deleted database. This may work fine as long as you only access the data that was cached in memory before the database was deleted, but once you need to access the deleted data on the disk, Derby will (correctly) raise container not found exceptions.

        If you insert this code in tearDown() after con.close(), it should work as you expect:

        try

        { DriverManager.getConnection("jdbc:derby:testdb;shutdown=true"); }

        catch (SQLException sqle)

        { // ignore expected shutdown exception }
        Show
        Knut Anders Hatlen added a comment - Thanks for providing the repro, Carl-Erik. I may be misunderstanding something, but here's what it seems to do: Repeat 4 times: 1) Delete the directory testdb 2) Connect to the database testdb, create if it doesn't exist 3) create tables 4) drop tables 5) commit I don't think this is valid usage, since the second iteration will delete a database that's currently booted. When you reconnect, you won't create a new database, but instead connect to the deleted database. This may work fine as long as you only access the data that was cached in memory before the database was deleted, but once you need to access the deleted data on the disk, Derby will (correctly) raise container not found exceptions. If you insert this code in tearDown() after con.close(), it should work as you expect: try { DriverManager.getConnection("jdbc:derby:testdb;shutdown=true"); } catch (SQLException sqle) { // ignore expected shutdown exception }
        Hide
        Carl-Erik Kopseng added a comment -

        This exact bug has been driving me nuts for two days. I find it hard to understand why practically no one else seems to have come across this. After long hours of trying to debug this I have stripped the code to the bare minimum to expose the bug consistently.

        The code in crashderby_src.zip contains a Java source code file along with two sql files. It is a JUnit test case and needs the junit4.jar as well as the derby.jar.

        Example (Linux): java -cp .:`locate /java/junit4.jar`:`locate lib/derby.jar` org.junit.runner.JUnitCore CrashDerby

        Show
        Carl-Erik Kopseng added a comment - This exact bug has been driving me nuts for two days. I find it hard to understand why practically no one else seems to have come across this. After long hours of trying to debug this I have stripped the code to the bare minimum to expose the bug consistently. The code in crashderby_src.zip contains a Java source code file along with two sql files. It is a JUnit test case and needs the junit4.jar as well as the derby.jar. Example (Linux): java -cp .:`locate /java/junit4.jar`:`locate lib/derby.jar` org.junit.runner.JUnitCore CrashDerby
        Hide
        Mike Matrigali added a comment -

        I took a quick look at the import code and can't see how the statement could return before it was finished. The
        error has more of the feel of a bad invalidation of whatever the second query you are running. Knowing exactly
        how this second query is synchonized with import returning may help understand what is causing the error.

        Can you perhaps provide a standalone example of the code that reproduces this issue?

        Show
        Mike Matrigali added a comment - I took a quick look at the import code and can't see how the statement could return before it was finished. The error has more of the feel of a bad invalidation of whatever the second query you are running. Knowing exactly how this second query is synchonized with import returning may help understand what is causing the error. Can you perhaps provide a standalone example of the code that reproduces this issue?
        Hide
        Daniel John Debrunner added a comment -

        There seem to be a couple of bugs here:
        1) the procedure should not return before it has finished.
        2) the container not found exceptions should not occur regardless of if the load has finished or not.

        Show
        Daniel John Debrunner added a comment - There seem to be a couple of bugs here: 1) the procedure should not return before it has finished. 2) the container not found exceptions should not occur regardless of if the load has finished or not.

          People

          • Assignee:
            Unassigned
            Reporter:
            Patty Parker
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development