I actually wasn't trying to make look DERBY-646 look better. I should
have been more clear. There was a durability mode we were talking about
that would be loosy-goosy about writing the log to disk, while at the
same time guaranteeing database consistency. You could potentially lose
the last N transactions on a crash, but your database would be rebootable.
David
Mike Matrigali wrote:
David Van Couvering wrote:
FYI, the issue with "durability:test" is not that you may lose some
data, it's that your data may become corrupt on failure and you won't
be able to reboot it. This is fine for unit testing, that's why it's
called "test".
I am not quite sure what point you are trying to make here.
It seems that you are saying DERBY-646 has less problems than
durability=test. With in memory you are guaranteed to lose your
database on reboot (which may be just fine for some apps).
DERBY-646 needs to be tested and documented. It sure would be nice to
get this in there, we keep getting this request.
David
Andrew McIntyre wrote:
On 7/31/06, Chris Forbis <[EMAIL PROTECTED]> wrote:
I was looking at derby and the FAQ says in Memory version has not been
completed, but to check with list.. It also said this about six
months ago
:) Just wondering if anything is being done on it...
This feature request is being tracked with DERBY-646 in JIRA:
http://issues.apache.org/jira/browse/DERBY-646
Feel free to pick up the work that has been done there and continue it
if you are interested. There are comments in JIRA that describe what
work remains to be done.
If you are not interested in working on the feature, and the
durability of your databases is not concern for you, then you could
achieve similar performance by running with the property
derby.system.durability set to "test":
http://db.apache.org/derby/docs/dev/tuning/rtunproperdurability.html
HTH,
andrew
