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
signature.asc
Description: OpenPGP digital signature
