manju sherif wrote:
Hi,
Is derby an in memory database ? We are looking at in memoery databases
for high reponse reads and inserts. How does Derby compare with HSQL as
an in memory database?
In-memory database support is on the Apache Derby To Do list at
http://db.apache.org/derby/DerbyToDo.html ; however, I don't believe it
is actively being worked on. The developers on this list can say for sure.
Dan Debrunner listed 2 key differences between hsql and derby in this
post to [email protected]:
http://mail-archives.apache.org/mod_mbox/db-derby-user/200409.mbox/[EMAIL
PROTECTED]
An extract from his post is down below:
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
I hope this helps.
regards,
-jean
