db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Reopened: (DERBY-306) Add relaxed durability that would ensure consistency and recoverability of the database
Date Wed, 14 Oct 2009 10:20:31 GMT

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

Knut Anders Hatlen reopened DERBY-306:
--------------------------------------


I think the in-memory database solves a different problem than the one described here, so
I'm reopening the issue.

There was a request for this on the user list not long ago: http://mail-archives.apache.org/mod_mbox/db-derby-user/200907.mbox/%3c82f04dc40907221252l3b79fd33sf35f33abe8556541@mail.gmail.com%3e

If you have a write-intensive application and you care about the consistency/recoverability
of the database but accept loss of some transactions in case of a crash, relaxed durability
could increase the performance significantly. An in-memory database is not an option in such
a scenario, because it's not persistent and its size is limited by the available memory.

One example use case:

I have an application[1] that processes a large body of documents[2] and stores some aspects
of it in a database. The indexing of the documents can be stopped and re-started, and the
application is able to read from the database how far it got before it was aborted, and it
knows how to continue from that point.

The indexing takes quite some time because of I/O wait on commit, and it's much quicker with
derby.system.durability=test. However, with derby.system.durability=test, if there's a crash
while indexing the documents, the database is likely to be corrupted and must be recreated
from scratch. Since the application is able to read from the database how far it got, it is
OK to lose some transactions, as the application thinks that it didn't perform them in the
first place and will happily continue from the point of the latest persisted transaction and
redo the lost transactions.

If we had a crash-safe variant of derby.system.durability, this process would be much faster,
but an in-memory database couldn't be used because of lack of persistence and because the
database is too big to store in memory.

[1] The application is OpenGrok (http://www.opensolaris.org/os/project/opengrok/)
[2] The body of documents is the source code for all the projects indexed at http://src.opensolaris.org/source/

> Add relaxed durability that would ensure consistency and recoverability of  the database
> ----------------------------------------------------------------------------------------
>
>                 Key: DERBY-306
>                 URL: https://issues.apache.org/jira/browse/DERBY-306
>             Project: Derby
>          Issue Type: Improvement
>          Components: Store
>    Affects Versions: 10.1.1.0
>            Reporter: Sunitha Kambhampati
>
> Add a relaxed durability option that would ensure that the database is consistent and
would recover.  Use the property derby.system.durability to support this option. 
> Some discussions earlier on the list, follow the thread given by this link)
> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200504.mbox/%3c425D5A64.8060507@gmail.com%3e
> Also see Derby-218.

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


Mime
View raw message