On Sun, 2007-06-17 at 11:19 +0200, bm@... wrote:
> Quoting Alex Roitman <shura@...>:
> >> Also, if two people work on the same database from a share, why can th=
> >> work simultaneously.
> > Two reasons:
> > 1. We open transactional environment in such a way that only
> > one process can access it. So two instances of gramps will
> > not be able to have the data open at the same time. The second
> > instance will get DB exception when trying to open it.
> I can do this on my PC with 2.2.8, opening twice the same db and changing=
> in different parts. No exceptions happen, but on close and startup; the g=
> does not load anymore with an error....
> I think I would prefer to see an exception instead of corrupt data :-)=20
> Anyway, I
> do like opening GRAMPS twice, using the second one to browse for somethin=
> I suppose the corrupt data is due to your next point (2.) ? As if they=20
> could use
> the same environment, it should not result in corrupt data (??)
We are treading on some dangerous area here with BSDDB. Remember, BSDDB
is not meant to be used in this manner. Only one process should be
accessing (not just changing, but accessing) the database at any given
I have given this a bit of thought, and I'm not sure exactly how to
prevent two processes from doing this. File locking only reliably works
if you are the same machine. You can get reliable NFS locking if you
install the the nfs file locking support. Over SMB, it is anyone's
Another option involves writing our own "lock" file in the database
directory, but we have to be careful of the case where someone crashes
(either the GRAMPS project crashes, the netowork crashes, or the system
crashes) while editing the database, leaving the lock file in place. How
does Aunt Martha clear this out, or know when it is really safe to clear
> I get your point, we would need a database server on the machine that has=
> grdb file, so only one process that does the transactions, going=20
> counter to the
> present BSDDB concept of a database manager incorporated in GRAMPS.
Exactly! This is why systems like MySQL have a dedicated server process
on a machine to handle this.
This is also while MySQL is non-trivial for most users to maintain. We
get into system startup files, gramps daemons running, and a whole mess
of other stuff. And when you consider that probably under 5% of the
users would be interested in something like this, we have to wonder
about our return on investment. Is our time more valuable working on
> I would suggest this for a next summer of google code project :-) It=20
> has nothing
> to do with boring genealogy so students might be interested, and GRAMPS i=
> getting more linux media attention, so it might just work (I fail to see =
> one more mp3 player application with many developers is getting funding a=
> opposed to the only stand-alone genealogy app). Perhaps you should write =
> short wiki page on the developers section with what would be needed.
Be careful here! Alex. is a bit sensitive about the Summer of Code
program. He put in a considerable amount of work to get us in the
program last year, only to be rejected. The usual MP3, RSS, and other
"popular" programs got all the attention.
And even if we did get this, the bigger issue is maintaining it.
Experience has shown me that Alex or I need to understand all code that
goes into the system, because we end up maintaining the vast majority of
code that gets submitted to us.