Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (hermes.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Message-ID: <41409451.6060506@debrunners.com>
Date: Thu, 09 Sep 2004 10:35:13 -0700
From: Daniel John Debrunner <djd@debrunners.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4.1) Gecko/20031008
MIME-Version: 1.0
To: Derby Discussion <derby-user@db.apache.org>
Subject: Re: Derby vs. HSQL but apache win
References: <7D3CC6609ECDB64A949E1096E2CA6BE8FD79DF@VEX1.ds.leeds.ac.uk>
In-Reply-To: <7D3CC6609ECDB64A949E1096E2CA6BE8FD79DF@VEX1.ds.leeds.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
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.
http://hsqldb.sourceforge.net/doc/guide/ch01.html#N1021D


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:
http://hsqldb.sourceforge.net/doc/guide/ch02.html#N104D5

>
> 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?'.


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

iD8DBQFBQJRRIv0S4qsbfuQRAje+AKCd0z4jSPNCgSuQ4RjGR6pDBiJthwCeL7w1
0SIT1k/E3c9OCXUrJvpp/Ug=
=ENJk
-----END PGP SIGNATURE-----