db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steen Jansdal" <st...@jansdal.dk>
Subject Re: Faster Derby with relaxed durability
Date Tue, 15 Feb 2005 23:00:20 GMT
I don't want the database to be unsafe by default, but an
option to run it in "non fail safe" mode. And this mode should
be possible to enable without recompiling.


> 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