db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6327) Give applications a way to request that Derby consistency-check crashed databases.
Date Fri, 30 Aug 2013 18:02:52 GMT

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

Rick Hillegas commented on DERBY-6327:
--------------------------------------

Thanks for listing those other areas where we could improve our consistency checking, Mike.

As a philosophical aside, I don't think that any complex data manager can "guarantee" that
the data is consistent and correct. At best, a complex data manager can merely assert that
it can't detect any defects. For Derby and other RDBMSes, it's also true that:

1) The risk that your data is defective goes up every time the database crashes.

2) The risk that your data is defective goes up further if the RDBMS can't complete crash
recovery successfully.

After a disaster, the end-user has 2 options:

i) Carry on with the latest dataset even though the risk of defects has gone up.

ii) Throw away the most recent changes and go back to an older snapshot whose risk of defects
is lower.

In my experience, most end-users go for option (i). They want a data manager which maximizes
support for that option.

Thanks,
-Rick

                
> Give applications a way to request that Derby consistency-check crashed databases.
> ----------------------------------------------------------------------------------
>
>                 Key: DERBY-6327
>                 URL: https://issues.apache.org/jira/browse/DERBY-6327
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL, Store
>    Affects Versions: 10.11.0.0
>            Reporter: Rick Hillegas
>
> It is common for operating systems to scan/repair the entire file system after a machine
crash. Similarly, it may be possible/desirable for Derby to consistency-check conglomerates
when a database is booted after coming down ungracefully. A couple issues are worth considering:
> 1) This could be an expensive operation on a large database.
> 2) Derby can't tell the difference between a machine crash and an application crash.
> The behavior change would be noticeable for complex, crash-prone applications with large
databases. That argues against making this the default behavior. Applications would need to
opt into this extra consistency checking.
> This enhancement request comes out of a discussion on DERBY-5221.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message