db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: Derby vs. HSQL but apache win
Date Thu, 09 Sep 2004 17:35:13 GMT
Hash: SHA1

Jianhui Jin wrote:

> Just turn auto-commit off, run 10000
> Not so much difference between derby and hsql, but still slightly
> slower, about 50% slower.
> But I will still go for Derby, because I trust apache,

No doubt there are situations where Derby is suitable and where HSQL is
suitable. Users just need to understand the different goals for the two
projects, or at least the differences in their current implementations.

These are two main differences I see from a quick look at the HSQL docs.

Memory Use

Derby is setup like a traditional database system where data is stored
on disk and a subset of that data is cached in a buffer cache or pool.

HSQL by default uses MEMORY tables (for standard CREATE TABLE
statements), this always stores the entire data in memory. Thus this is
fast, but obviously consumes memory. It is useful to look a process
sizes as well as absolute times when running benchmarks.

Transaction Model

Derby provides a complete thread-safe multi-connection model supporting
all four JDBC/SQL isolation levels. Row level locking is used to support
these isolation models.

HSQL provides the single isolation level, READ_UNCOMMITTED, also known
as dirty read, even for update transactions. Issues with this model are
described in the HSQL documentation at:

> hope a new release come soon. I need a stable version urgently for my
> contract.

I started a thread on the developer list about starting a release,
the subject is 'thoughts on a release?'.

Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


View raw message