Skip to main content

Why Use Java DB For Web Client Storage?

Posted by davidvc on November 17, 2006 at 7:28 PM EST

I've been wanting to write about the value of a relational database (and Java DB in particular) when implementing local storage in web clients. The announcement of Zimbra's offline support and the dialog on their blog of why they chose Derby over dojo.storage has motivated me to get these thoughts out there.

Why would you want to use a relational database (and particularly Java DB) for local storage rather than other solutions, such as the WHATWG API implemented in Firefox 2.0 or the dojo.storage package , which provide a simpler key/value storage mechanism?Here are some of the key benefits of using a relational database:

  • Transactions - most relational databases implement transactional semantics. This means that operations on your data are done in such a way that they are ACID - Atomic, Consistent, Isolated, and Durable. Transactional semantics ensure that your data is not corrupted, lost, or viewed in inconsistent ways. Like backups, often this doesn't seem important, and then it becomes very important.
  • Queries - one of the key values of a relational model is the ability to issue dynamic queries over your data set. Without a relational query engine, you will have to build your own query functionality yourself.
  • Joins - Joins let you take two tables in a query and "join" them together to get a view of your data that looks like a new table. Without this feature, applications end up being locked in to a particular data model and it's very difficult to create and manipulate new views of data. Joins also allow you to avoid duplication of data across multiple tables.
  • Caching - Most relational databases implement data caching for you, bringing significant performance savings. Depending on which key/value storage API you use, you may find yourself having to implement your own caching depending on your performance needs.
  • Indexes - also called access methods, indexes allow quick access to data for common access patterns. A key/ value model has a single index you get for free. If you want secondary indices, you have to build them yourself.
  • Well-established standards - Using well-established standards like SQL and JDBC avoids vendor lock-in and expands the pool of engineers who will have the skills needed to work on your code base.

Why Java DB / Apache Derby?

Java DB is Sun's supported distribution of Apache Derby. Java DB is very well suited to serve as the local store for web clients for a number of reasons:

  • 100% Java - This means portability. Java DB even runs on the CDC (Connected Device Configuration) profile of the Java 2 Micro Edition (J2ME). This means your application will be able to play in the mobile space if and when that becomes an opportunity for you.
  • Small footprint - Java DB is a single jar file with a runtime footprint of 2MB. Using Pack200 it can be compressed down to 700K. Pretty impressive for a fully functional relational database.
  • Transactional - Not all relational databases are created equal. Some trade off size and speed for potential loss or corruption of data. Java DB supports full transactional semantics.
  • Embeddable and Zero Administration - Java DB can run embedded in the same VM as your application (and thus embedded in the browser's VM too). It also in most cases can be brought up without any administration - your first connection to the database automatically boots it up. Recovery and upgrade are also automatic. This is key when you're trying to provide a solution that is used by consumers or naive users and you don't even want them to know there's a database under the covers.

There are lots of situations where a simple key/value storage mechanism works just fine. It is simple, easy to understand, and you can generally get productive sooner. But when making a decision, look at your current and future requirements and make sure that key/value is going to meet your needs.

Blog Links >>