db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McIntyre" <mcintyr...@gmail.com>
Subject Re: Startup time for Derby
Date Thu, 03 Aug 2006 04:51:04 GMT
On 7/27/06, David Van Couvering <David.Vancouvering@sun.com> 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.

This is something that has come up in the past and I just had a random
thought regarding this.

The structure of a new, properly shutdown database has to be static
for a specific version of Derby, right? (ok, almost, see locale note
below)  So, what if we packaged a new database in a jar file,
derbynewdb.jar, along with its exact version info, and when a
connection URL with the create attribute is passed, the engine checks
that newdb.jar is available and that the version of the newdb jar file
in the classpath is identical. If so, the engine expands the new,
empty database from the jar into the local filesystem instead of
creating all of the system tables from scratch. If the version
mismatches or the newdb.jar isn't there (or is incomplete?), we create
a new db from scratch the regular way. A new db compressed into a jar
file is only 54K for 10.2, not so bad for (re)deployment.

Someone has to have thought of this before, so I'm wondering what the
issues are here. One problem that I can think of off-hand would be
that a database is created with the JVM's current locale as the
database locale. So it would be necessary to have a way to update the
database locale after the expansion of the new db from the jar file,
maybe a system procedure that needs to be called after the expansion
of the new database from the jar. Another is what if there is a
failure while uncompressing the db, what do you do on an attempt to
reconnect? There would need to be a way to verify that you're working
with a full deck of cards, as it were, but such a verification still
seems like it would be less heavy-weight than creating a new db from
scratch.

Anyway, the idea passed through my head, so I thought I'd throw it out there...

andrew

Mime
View raw message