[ 
https://issues.apache.org/jira/browse/DERBY-2639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12860164#action_12860164
 ] 

Knut Anders Hatlen commented on DERBY-2639:
-------------------------------------------

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
}

> Bulk data load utility should indicate when it is finished.
> -----------------------------------------------------------
>
>                 Key: DERBY-2639
>                 URL: https://issues.apache.org/jira/browse/DERBY-2639
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.2.2.0
>         Environment: Java Version:    1.5.0_06
> Java Vendor:     Sun Microsystems Inc.
> OS name:         Windows XP
> IDE:  Eclipse
> Derby:  10.2.2,  running Embedded
>            Reporter: Patty Parker
>         Attachments: crashderby_src.zip, DerbyProblem.jar
>
>
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to