I have to agree, we need a more useful "memory-based" solution that
guarantees consistency if not durability.
David
Francois Orsini wrote:
*uh* ;)
Well I sure would not run a production application with relaxed
durability turned on ;) *unless* 1) I can guarantee my system will never
crash _or_ 2) my databases are completely read-only (not even sure we
would not still see issues here with the log but this is just
speculation assuming temp files used for large sort ops are not logged
), 3) _or_ tha t I would not care to rebuild my DBs in case of
corruption, etc...
"Once the database is booted with derby.system.durability=test, there
are no guarantees that the database is consistent."
On 10/11/05, *Daniel John Debrunner* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Norbert Toth-Gati wrote:
> Hi David,
>
> I have changed some mails with Stephen Fitch, he said he is
working on this.
> If feature is requested so frequent, is it possible to hope it will
> get a higher priority and get some where in the front of the TODO
> list?
Why do you need an in-memory version of Derby? Have you tried Derby
with
the relaxed durability if you are concerned about performance?
http://db.apache.org/derby/docs/10.1/tuning/rtunproperdurability.html
<http://db.apache.org/derby/docs/10.1/tuning/rtunproperdurability.html>
Providing a good reason whty something is needed is a definite help in
motivating people to scratch that itch! :-)
Dan.
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
