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...
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
Mike Matrigali wrote:
I would like to participate in the discussion on this, let me know what
you prefer (list, jira, wiki). As dan said I believe there are many
parts to this issue and would like to see them broken down. I also do
think there is a perception issue also and not quite sure how to
address it, do the db's we are being compared to allow create and
connect in the same jdbc statement?
My initial take is:
1) pick a platform and do some measurements, need to know if the
platform properly sync's the disk when asked.
2) compare creating empty database with copying an empty database
template from a jar file, with copying an empty database template
from disk. I do not think derby should go to template based
approach for creating database. I also witnessed a number of
bugs/harder to maintain code in 2 previous companies I worked at which
used this approach, where the current approach has been maintainable
from the start in derby. I do think that if copying from a template is
faster, then we should just document to users how/why they should do it
if creating a db is a critical performance point for their application.
Derby already fully supports this (at least from disk), it is exactly
what restoring from a backup does and we already support restoring a
single db to multiple other data locations.
3) break up the "startup" cost issue into measureable understandable
pieces, as dan laid out -- just to make sure we are fixing the
right problem. I really want to separate "startup" issues from
creating a new db issues.
David Van Couvering (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1664?page=all ]
David Van Couvering reassigned DERBY-1664:
------------------------------------------
Assignee: David Van Couvering
Derby startup time is too slow
------------------------------
Key: DERBY-1664
URL: http://issues.apache.org/jira/browse/DERBY-1664
Project: Derby
Issue Type: Improvement
Components: Store
Reporter: David Van Couvering
Assigned To: David Van Couvering
Fix For: 10.2.0.0
I know it's hard to measure what "too slow" is, but this is a common
complaint and this affects overall perception of Derby. This appears
to be related to another common complaint that it takes too long to
create tables. I am marking this as Urgent because of the impact it
has to Derby perception and the fact that the 10.2 release is going
to get such wide distribution through the Sun JDK.
For background, see
http://www.nabble.com/Startup-time-tf2012748.html#a5531684
