db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernt M. Johnsen" <Bernt.John...@Sun.COM>
Subject Re: Derby as desktop database
Date Thu, 29 Jun 2006 10:07:34 GMT
Hi Andrus!

After you left, we were playing around with the problem and were
thinking along the same lines as your second solution. Some peer-to-peer
protocol or some multicast membership protocol (e.g. something like
JGroups http://www.jgroups.org/javagroupsnew/docs/index.html. I have
done similar stuff before, and with the proper library, it's not that
hard to implement) for group communication and voting for a master
(which would be the server). The system should distribute information on
where the server is and put up local connection pools which should be
invalidated when the master dies. If the master dies another master is
voted for.

The application should be written with the proper catch/rollback/retry
cycles for transactions, since losing the connection as a transient
error in such a system. (We've been working with distributed databases
before, so this is just something you have to do when you're starting to
distribute database usage).

Bernt & Olav

Andrus Adamchik wrote:
> I've been looking for some time for a good embedded database that  would
> work for desktop applications. Derby is ideal for that and I am 
> starting to use it more and more in various examples and tutorials  that
> I am writing for Cayenne. But there is one feature that I am  missing in
> Derby (or any other database for that matter) - an ability  to share the
> same database between multiple desktop applications (or  multiple VM
> instances of the same Java application).
> I asked this question the Derby folks from Sun at ApacheCon in Dublin 
> the other day and the answer was basically - run the network server.  In
> other words db sharing and embedded mode are not compatible. So I 
> wonder what it would take to make it compatible?
> Since we are talking desktop apps, the following conditions are at play:
> (a) all apps run on the same machine (but in different VMs)
> (b) usually only one instance at a time would work with the database, 
> but other instances can occasionally access the db in the background 
> (no need to deal with massive concurrency)
> (c) usually the database is small-to-medium size.
> Any ideas? One possible solution is cloning the DB for each instance 
> and using multicast for peer-to-peer synchronization.
> Another (more promising) is to do collaborative peer-to-peer  connection
> pool (DataSource), so that when a client needs a local  Derby connection
> it sends a multicast so that current lock owner in a  different VM can
> finish its thing, shutdown Derby and release the  lock. I wonder if
> anyone have done that already?
> Andrus
> ------------------------------
> Andrus (aka Andrei) Adamchik
> Cayenne Persistence Framework
> Creator, Committer
> http://incubator.apache.org/projects/cayenne.html

Bernt Marius Johnsen, Database Technology Group,
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway

View raw message