 |
Why Use Java DB For Web Client Storage?
Posted by davidvc on November 17, 2006 at 04:28 PM | Comments (9)
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.
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
I agree, it's a good choice. I'm using it for storing the (rather complex) data structure behind a desktop application for managing photos. Indeed using a SQL database for such things is state-of-the-art - e.g. Adobe Lightroom uses SQLite and I can remember having seen the first products doing such a thing with MS Access on Windows three years ago. But clearly a 100% Java product simplifies a lot of things.
At the moment I've got some problems with performance, but it's so blatant that for sure there's some trivial error - maybe I've forgotten creating the indexes for some tables.
Posted by: fabriziogiudici on November 17, 2006 at 05:18 PM
-
Isn't this apples and oranges? I mean, the Zimbra offline functionality isn't even really about the same domain-targeted local storage that Flash/WHAT-WG provides and requires a level of app deployment that is significantly higher. Nevermind that the WHAT-WG and Flash stuff actually works right talking to JavaScript applications and Applets/LiveConnect are hit or miss at best.
Please correct me if I am wrong here, but it looks like the Zimbra app is just a desktop app you download and run as a local service for the client. It is no more a "web" app than Google Desktop. Don't get me wrong, at my job we are actually looking at taking a current Online/Offline dual application and making the "desktop" version the run as an embedded Tomcat app using Derby on the local machine and the same browser UI is used for both. This is still a "Desktop" application, however. It still has to be provisioned to the client system -- we looked at WebStart and while a great technology, it is just not up to it -- so it is not as easy as just entering a URL and being away.
Flash/DOJO and WhatWG are ways for Web apps to store small bits of information on the client and that can be good for storing prefs and local app state to save server resources and programming hoops, but if "running" the application means hitting "http://foo.com/barApp/" to start it, you still aren't talking about an "offline" data storage. It is just programmer utility space. Indeed, even saving too many preferences out side of local application state there seems like a bad idea to me since preference changes would be different across machines, costing one of the great use advantages of web based applications in a world where people use the same app on 3-4 devices regularly.
Posted by: kebernet on November 17, 2006 at 06:23 PM
-
zebernet: I totally agree that there are great uses for WHAT-WG and dojo.storage/Flash. But I think it's important to recognize and make these distinctions. Brad's initial introduction of dojo.storage advertised it as being useful for offline storage. I think you just need to be aware of strengths and weaknesses and what you want to use it for and try to make an informed best choice.
Regarding what's a desktop app, I think there is a subtle distinction between a Rich Internet App (RIA) and destkop app, where one relies on the collaborative nature of the web and one uses the Internet very little if at all.
Interesting choice of architecture, using an embedded Tomcat server. I've looked at that, and it seems to be the way a lot of folks are going (Google appears to be going this way too). It does allow you to use the same UI for online and offline, which is nice.
Posted by: davidvc on November 17, 2006 at 06:37 PM
-
Just a quick note: the next version of Dojo Storage, the 0.4.1 release going out in the next few days, will have transparent support for Firefox 2's new native client side storage. This means when Dojo Storage starts it first looks for a WHAT WG native client store, which is what Firefox 2 has, and then falls back on hidden Flash if it is not available. This further extends the reach of using Dojo Storage across the existing web, _without_ having to install new software. Special thanks to JB Boisseau for submitting the WHAT WG dojo storage provider.
Best,
Brad Neuberg
Posted by: bradneuberg on November 18, 2006 at 03:25 AM
-
Just to show the deployment strength of Dojo Storage, going to http://codinginparadise.org/projects/dojo_storage/release/dojo/demos/storage/editor.html in your browser will instantly load in Moxie, a demo app for Dojo Storage that is a web editor with persistent client-side storage and offline access. Plus, it works with Safari, IE, and Firefox, across the existing installed base. No Java Web Start, no downloading any apps, nothing; it just works. See http://manual.dojotoolkit.org/WikiHome/DojoDotBook/Book50 for full docs on Dojo Storage.
Best,
Brad
Posted by: bradneuberg on November 18, 2006 at 03:28 AM
-
About offline storage; David is right that I promoted Dojo Storage for offline access. There are two kinds of offline access for web apps:
1) You are on the network, with your app open in the browser, then the network drops or you leave it. You then go onto an airplane or work away from the network. Your data is stored in the local cache. When you get off the airplane or hit the network again, your data syncs. The whole time your browser remained open with the app already loaded when you were on the network -- its just that the network behind it might have dropped in the middle of your work.
2) You are not on the network, but want to access both your application and it's data by simply opening the browser. There must be some way for the app to fetch it's UI and data without being able to talk on the network.
Dojo Storage immediately supports offline type 1 today; this is robust and supported, though there are no syncing APIs currently. #2 is supported experimentally, using some magic HTTP caching headers for the UI, discovered by Julien Couvreur, along with the durable cache provided by Dojo Storage. #2 is not as robust, though, since pulling the UI from the local browser cache might result in a cache miss; you're data is safe inside of Dojo Storage, though.
Posted by: bradneuberg on November 18, 2006 at 03:32 AM
-
I just wanted to say I support David's work and Derby/Lucene. Dojo Storage and Derby have different use cases, and are appropriate for different domains. If you are doing something like Zimbra, where you have a tremendous amount of data that you need to do full text indexing and hard core querying on, then Derby/Lucene make sense. If ease of deployment and the existing installed base are important, and your data resembles more of a hashtable model with key/value pairs (more like Berkeley DB), then Dojo Storage makes sense.
Best,
Brad
Posted by: bradneuberg on November 18, 2006 at 02:00 PM
-
H2 can be used as the database engine as well. Like Derby, H2 is pure Java, transactional, embeddable, zero admin and small footprint (about half as big as Derby). (I am the author of H2).
Posted by: thomasmueller2 on November 19, 2006 at 09:21 PM
-
I wanted to respond to Brad's comment about how if you use dojo.storage you don't have to do any install, it just works. I think that's a bit misleading, because you do need to install Flash, it's just that most browser come with Flash pre-installed. With Java going open source, I don't think it's a far leap to assume that the Java Plugin will be pre-installed with most operating systems in the near future. So you have the same "no install required" experience with Java DB as you do with dojo.storage/Flash or WHATWG implementations.
I also think it's important to note that Java Web Start is not required for using Java DB as local storage, although it is one option. That said, Java Web Start is so insanely simple that I think it's unfair to call that "installing an application." You click on the JNLP URL, you get a splash screen for a few seconds, and you're off and running.
I'm saying these things because I think Java gets a bad rap as a deployment platform on a web client. I agree with Brad that dojo.storage/WHATWG is a perfect fit for many solutions. But I don't think ease of deployment should be a major factor when deciding whether or not to use Java DB.
Posted by: davidvc on November 21, 2006 at 11:05 AM
|
java.net RSS Feeds
