Cool. I actually started prototyping something similar this morning,
with one difference that I am not defining a master server, but
rather making it peer-to-peer (where the ownership of the database is
transferred on demand between the applications). This will likely
reduce the throughput (as reassigning the ownership would require a
full shutdown), but hopefully address the need to handle dropped
connections.
Cayenne has a generic distributed EventManager (with pluggable
transports, JavaGroups being one supported option) that I can try for
this purpose. We'll see how that works.
Andrus
On Jun 29, 2006, at 11:07 AM, Bernt M. Johnsen wrote:
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
