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 08:42:59 GMT
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


Mime
View raw message