A little background: Sometime earlier on the list, Dan posted a fix to
make derby go faster with relaxed durability with some flags. The post
is at
http://article.gmane.org/gmane.comp.apache.db.derby.user/681/match=relaxed+durability
This mode is very useful for unit testing or at development t
Hi, Sunitha. Thanks for your work on this. My comment is more a
"marketing" comment than a technical one. I disagree that this is
useful only for testing and development. As I mentioned in previous
emails, there are a number of customers who may find this very useful
indeed, who are willing
I am looking at committing this patch.
Sunitha Kambhampati wrote:
A little background: Sometime earlier on the list, Dan posted a fix to
make derby go faster with relaxed durability with some flags. The post
is at
http://article.gmane.org/gmane.comp.apache.db.derby.user/681/match=relaxed+durabi
As I have posted before I have concerns about this mode, as it can
definitely produce a database which can not boot. But the discussions
here convinced me
that it was useful for a number of applications, so now believe it
should be checked in. I definitely have no career path in marketing
as my f
suresh, you have done a lot of work in this area could you review
the patch and post your comments?
Sunitha Kambhampati wrote:
A little background: Sometime earlier on the list, Dan posted a fix to
make derby go faster with relaxed durability with some flags. The post
is at
http://article.gman
After I wrote my email, I wondered if the feature as currently
implemented wasn't quite what I was thinking we should have. I agree
that if you potentially can't boot your database, this is not a
production-level feature.
I second the motion to see more work done to implement the relaxed
dura
sure. I will review it.
-suresh
Mike Matrigali wrote:
suresh, you have done a lot of work in this area could you review
the patch and post your comments?
Sunitha Kambhampati wrote:
A little background: Sometime earlier on the list, Dan posted a fix
to make derby go faster with relaxed durabilit
This patch disables syncs for
- 1)the log file at each commit
- 2)the log file before data page makes it to disk
- 3)data page allocation when file is grown
- 4)data writes during checkpoint.
Thus, when this mode is enabled, syncs are not enforcing proper WAL
protocol and might lead to databa
I think testMode isn't very clear what it's doing. I agree that
relaxedDurability is not correct because it doesn't communicate that you
may not be able to boot the database.
How about derby.system.fast-and-loose :)
Seriously, how about
derby.system.durability=test
(you can't really say "none"
I like this name : derby.system.durability=test
I will wait for Suresh's comments and then change the name of the
property after that unless someone else has a better suggestion.
Thanks for your input.
Sunitha.
David Van Couvering wrote:
I think testMode isn't very clear what it's doing. I agr
this seems fine with me. I agree none does not seem right, none seems
more appropriate if an in memory implementation is ever provided -
though derby.system.durability=memory seems better than none in that
case.
I like that a setting that says "test" forces someone to think about
what they are set
David Van Couvering wrote:
> I think testMode isn't very clear what it's doing. I agree that
> relaxedDurability is not correct because it doesn't communicate that you
> may not be able to boot the database.
>
> How about derby.system.fast-and-loose :)
>
> Seriously, how about
>
> derby.system
My two cents:
How about cryptic one like
derby.system.durabilityLevel = 0
0 - mean none.
That way some one using it will be forced to read the doc and find
out what it mean :-)
-suresht
Daniel John Debrunner wrote:
David Van Couvering wrote:
I think testMode isn't very clear what it's
Hi Sunitha,
Good comments. I am surprised to find that this patch doing more than
what I imagined it will do, your changes
seems to allow switching between durable test mode(No syncs) and the
default durability level (all sync). I don't get why
these mode switch functionality is required, if
I think that once the db is run in this mode it should be marked, and
not worry about ever unmarking it. At first I just thought this was
necessary to explain lost transactions, but I agree with the case below
- successful recovery/booting does not guarantee consistent database.
The case that you
Thanks Suresh for your comments. I have attached a new patch that takes
care of them and as well as the property name change as discussed on the
list.
So now,
1)To enable this no syncs mode, the property setting is
derby.system.durability=test
If it is set to any other value other than test
Could you resolve the conflict in LogToFile.java in the current trunk
revision and resubmit the patch?
Sunitha Kambhampati wrote:
Thanks Suresh for your comments. I have attached a new patch that takes
care of them and as well as the property name change as discussed on the
list.
So now,
1)To e
Mike Matrigali wrote:
Could you resolve the conflict in LogToFile.java in the current trunk
revision and resubmit the patch?
I resolved the conflict and regenerated the
patch(DurabilityTest_0510.txt). Let me know if you have any problems
applying this patch.
Thanks,
Sunitha.
Sunitha Kambhampati
I committed this change with svn 169538.
Sunitha Kambhampati wrote:
Mike Matrigali wrote:
Could you resolve the conflict in LogToFile.java in the current trunk
revision and resubmit the patch?
I resolved the conflict and regenerated the
patch(DurabilityTest_0510.txt). Let me know if you have any p
Great! I have a question: if I wanted to use this to speed up testing,
how do I do it within the context of the test harness?
Thanks,
David
Mike Matrigali wrote:
I committed this change with svn 169538.
Sunitha Kambhampati wrote:
Mike Matrigali wrote:
Could you resolve the conflict in LogToFile.
David Van Couvering wrote:
Great! I have a question: if I wanted to use this to speed up
testing, how do I do it within the context of the test harness?
To enable this mode for derbyall suite.
put the following property in
java\testing\org\apache\derbyTesting\functionTests\suites\derbyall.prope
Sunitha Kambhampati wrote:
David Van Couvering wrote:
Great! I have a question: if I wanted to use this to speed up
testing, how do I do it within the context of the test harness?
To enable this mode for derbyall suite.
put the following property in
java\testing\org\apache\derbyTesting\function
Sunitha Kambhampati wrote:
> David Van Couvering wrote:
>
>> Great! I have a question: if I wanted to use this to speed up
>> testing, how do I do it within the context of the test harness?
>>
> To enable this mode for derbyall suite.
> put the following property in
> java\testing\org\apache\der
let us know if this works. There are some recovery/crash tests in the
full suite. My guess is that they will work since the I/O is sent to
the OS, just not sync's -- but they are not guaranteed to work under
this mode.
Sunitha Kambhampati wrote:
David Van Couvering wrote:
Great! I have a questio
Thanks. Are there any tests that *shouldn't* be run in this mode, e.g.
recovery tests?
David
Daniel John Debrunner wrote:
Sunitha Kambhampati wrote:
David Van Couvering wrote:
Great! I have a question: if I wanted to use this to speed up
testing, how do I do it within the context of the test
FYI, your suggestion worked great on XP, but on Linux I got a strange
error in tests that spawn another JVM:
Exception in thread "main" java.lang.NoClassDefFoundError:
"-Dderby/system/durability=test"
I am will try to track this down, but meanwhile I'm modifying
derbyall.properties...
David
D
FYI, your suggestion worked great on XP, but on Linux I got a strange
error in tests that spawn another JVM:
Exception in thread "main" java.lang.NoClassDefFoundError:
"-Dderby/system/durability=test"
I am working on tracking this down, but meanwhile I'm modifying
derbyall.properties...
David
David Van Couvering wrote:
> FYI, your suggestion worked great on XP, but on Linux I got a strange
> error in tests that spawn another JVM:
>
> Exception in thread "main" java.lang.NoClassDefFoundError:
> "-Dderby/system/durability=test"
Getting the quoting to work when passing setting jvmflags
Thanks, Dan. Yes, I would love to move to JUnit too, that has my vote.
David
Daniel John Debrunner wrote:
David Van Couvering wrote:
FYI, your suggestion worked great on XP, but on Linux I got a strange
error in tests that spawn another JVM:
Exception in thread "main" java.lang.NoClassDefFoundErr
> "SK" == Sunitha Kambhampati <[EMAIL PROTECTED]> writes:
SK> A little background: Sometime earlier on the list, Dan posted a fix to
SK> make derby go faster with relaxed durability with some flags. The
SK> post is at
Thanks for the feedback.
Øystein Grøvlen wrote:
<>Even if it is a bit late, here are some questions/commentsto this
patch and the follow-up patch for the test program:
- I am not sure about the value of this mode compared to a mode with
relaxed durability, but guaranteed consistency. The larg
31 matches
Mail list logo
