You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kathey Marsden (JIRA)" <ji...@apache.org> on 2008/07/07 21:02:31 UTC

[jira] Updated: (DERBY-3393) Database corruption when adding sleep() in RAFContainer4.writePage()

     [ https://issues.apache.org/jira/browse/DERBY-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kathey Marsden updated DERBY-3393:
----------------------------------

    Derby Categories: [High Value Fix]

> Database corruption when adding sleep() in RAFContainer4.writePage()
> --------------------------------------------------------------------
>
>                 Key: DERBY-3393
>                 URL: https://issues.apache.org/jira/browse/DERBY-3393
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.2.2.1, 10.3.1.4, 10.4.1.3
>         Environment: Solaris 10, OpenSolaris snv_80, Sun Java SE 5.0, Sun Java SE 6, Derby trunk #618305
>            Reporter: Knut Anders Hatlen
>            Priority: Critical
>
> In order to test whether RAFContainer4.writePage() was properly synchronized, I made it sleep for 100 ms each time after it had written a page, right before it set its needsSync flag to true, like this:
> Index: java/engine/org/apache/derby/impl/store/raw/data/RAFContainer4.java
> ===================================================================
> --- java/engine/org/apache/derby/impl/store/raw/data/RAFContainer4.java (revision 618305)
> +++ java/engine/org/apache/derby/impl/store/raw/data/RAFContainer4.java (working copy)
> @@ -350,6 +350,11 @@
>                      dataFactory.writeFinished();
>                  }
>              } else {
> +                try {
> +                    Thread.sleep(100);
> +                } catch (InterruptedException ie) {
> +                    // ignored
> +                }
>                  synchronized(this) {
>                      needsSync = true;
>                  }
> When I ran derbyall with this change, I saw some failures in the storerecovery suite. I reran the storerecovery suite a couple of times, seeing failures each time, although the actual failures varied a bit.
> The most common failure was the following (page numbers and container numbers varied):
> > Exception in thread "main" java.sql.SQLException: Failed to start database 'wombat', see the next exception for details.
> > Caused by: java.sql.SQLException: Failed to start database 'wombat', see the next exception for details.
> > 	... 17 more
> > Caused by: java.sql.SQLException: Page Page(19,Container(0, 1073)) is at version 0, the log file contains change version 578, either there are log records of this page missing, or this page did not get written out to disk properly.
> > 	... 14 more
> > Caused by: ERROR XSDB4: Page Page(19,Container(0, 1073)) is at version 0, the log file contains change version 578, either there are log records of this page missing, or this page did not get written out to disk properly.
> > 	... 14 more
> This failure was seen in oc_rec3, oc_rec4, dropcrash and dropcrash2.
> In some cases, I saw this failure in oc_rec3
> > Exception while trying to insert row number: 0
> > ERROR XBCA0: Cannot create new object with key Page(2,Container(0, 1040)) in PageCache cache. The object already exists in the cache.
> which would be followed by this error in oc_rec4:
> > ERROR 23505: The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'TEST1_2_IDX_INDCOL3' defined on 'TEST1_2'.

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