db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Faster Derby with relaxed durability
Date Tue, 15 Feb 2005 18:14:38 GMT
I think it is wrong to make non safe database the default, but am
interested in hearing the communities opinion.  I do realize other
database systems do pick this as their default.

I suggest that if it is decided to
"support" this mode that the logging system be changed to somehow
record that the database has operated in this manner, so that if
the database goes corrupt we don't waste effort trying to figure out
what when wrong.  Probably need some way to mark the log records, the
log control file and write a message to the user error log file.

Steen Jansdal wrote:

> Daniel John Debrunner wrote:
>> If you build Derby yourself you can test out a faster version of Derby
>> that has relaxed durability.
>> By relaxed durability I mean that:
>>  - a commit no longer guarantees that the transaction's modifications
>> will survive a system crash or JVM termination.
>>   - the database may not recover successfully upon re-start
>>   - a near full disk at runtime may cause unexpected errors (currently
>> Derby ensures that space exists on the disk
>>      for a transaction's data before commit)
>> This is useful for unit testing or development time.
>> I would not recommend it for production if your data is important.
>> I think this functionality should be added into the standard Derby but
>> in a simpler form,
>> maybe a single property
>> derby.storage.durable={full,none,???}  [not supported currently, see
>> below]
>> (or maybe even higher concept, derby.system.testMode=true??)
>> In the meantime ....
>> This will work on the 10.0 branch or the trunk
>> Set the variable MEASURE in
>> java/engine/org/apache/derby/iapi/services/diag/Performance to true
>> (see attached patch)
>> Clobber and then compile Derby
>> ant clobber
>> ant
>> Set these system properties when running Derby
>> derby.storage.dataNotSyncedAtCheckPoint=true
>> derby.storage.dataNotSyncedAtAllocation=true
>> derby.storage.logNotSynced=true
>> E.g.
>> java -Dderby.storage.dataNotSyncedAtCheckPoint=true
>> -Dderby.storage.dataNotSyncedAtAllocation=true
>> -Dderby.storage.logNotSynced=true your_application_class
>> If you are successful then you see this warnings in derby.log
>> Warning: derby.storage.dataNotSyncedAtCheckPointset to true.
>> Warning: derby.storage.dataNotSyncedAtAllocationset to true.
>> logNotSynced = true
>> This stops Derby flushing data all the way to disk, and thus in most
>> cases i/o cost is not involved as the operating file system cache keeps
>> all the data pages and log in memory.
>> If anyone tries this could they e-mail the list to say if it's
>> sufficient for their needs and if they would like to see this option
>> become part of a Derby release in its simpler form.
>> Thanks,
>> Dan.
> This is awesome. Please let this "not failsafe" option it be a standard
> option. I can see a lot of places where we don't need the database to
> be failsafe, but could use the extra speed.
> Steen

View raw message