db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [jira] Assigned: (DERBY-1664) Derby startup time is too slow
Date Fri, 11 Aug 2006 14:53:25 GMT


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.



Mime
View raw message