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
