Mike Matrigali wrote:
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??)
[snip]
How would this work - would one be able to start the database up in relaxed durability mode one day, and in cautious/normal mode another day? Or would it be once the database is created it always stays in that mode?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
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.
Myrna
