David Van Couvering wrote:
Oh, one more thing, the database I have heard us compared with is HSQL.
Folks don't expect us to be equivalent, given that HSQL is in-memory,
but they do complain that the difference is just a little too much, from
basically instantaneous to 10s of seconds...
hsql is an in memory db which does not do transaction based syncing,
derby is often not going to compare favorably when it does real
transaction based syncing, guaranteed recovery, can handle db's bigger
than memory, ...
The use cases I have heard of are unit testing (I think we've even
complained about this, our way of solving it is reusing the same
database :)), and during development where you're constantly rebooting
the server that has the database embedded. Another area of concern for
me is when the database is being created in a browser-embedded
application. Java already has a bad rap for slow boot-up time in those
environments...
David
definitely would like to see the db create issue separated from the
rebooting an existing db. And in the reboot case we should look at
"clean shutdown" vs. "crash with recovery shutdown". In the reboot
case last time we looked there was a big difference between 1st
load of derby classes and subsequent load, there was a linear penalty
per derby class (and unfortunately # of derby classes is growing
release to release); but it has been quite awhile since anyone looked
at this in detail.
