In this discussion it would be good to understand what "startup" means.
1) is the user "starting" up on an existing db. Our unit tests almost
always create a new database as part of the startup. Since creating
a new db and connecting is one step in derby, it is often difficult
to tell the difference.
2) is the user "starting" up on an existing database that has a lot of
recovery to do. Derby provides a way to shut down "cleanly" so that
no recovery is necessary at the next startup.
Michael J. Vinca wrote:
I can attest to it. My Java app had a very minimal startup time, until
I added a Derby database. Now it is very noticeable. I don't have any
specific numbers, just minimal to noticeable. :-)
On Jul 27, 2006, at 8:09 PM, David Van Couvering wrote:
I am here at OSCON and a user of Derby was complaining rather
energetically to me at the cost of startup time for Derby. He said
this is a real problem for running unit tests, as this is compounded
by running multiple tests, each one starting up a new database.
I was wondering if other users out there have a similar complaint and
if you can give a sense of how important this is. If you can
describe your specific usage pattern that would be very helpful.
Thanks!
David
