On Mon, 2004-12-13 at 10:42, Keith Bostic wrote:
> > This problem appears to be mostly fixed as a practical concern (I think
> > mostly by eliminating circumstances where rpm processes would exit
> > uncleanly), but it's still symptomatic of Berkeley DB's brittleness when
> > used as an embedded database.
>
> I can't really let that one go. :-)
I may have been unclear in my use of the term "brittle." I meant that
the software works as advertised, but imposes difficult requirements on
its consumer and can break in confusing and frustrating ways when those
requirements are not met.
If I thought BDB didn't work as advertised, I would have called it
"flaky." (In my defense, http://www.jargon.8hz.com/ essentially agrees
with my usage of these highly technical terms, although the examples
presented there for "brittle" are more severe than what I've experienced
with BDB.)
> To use Berkeley DB, you have to conform to its requirements for
> running database recovery -- which requirements are explicitly
> documented.
So, this doesn't contradict what I meant, though it may have
contradicted how I was interpreted.
(I'm not sure it's valid to say that we don't conform to BDB's
requirements about running database recovery. We just pass that
requirement onto the user, which isn't optimal.)
I apologize if I'm fostering ill will here. I think your offer is a
very good one, and I wish I had the time to personally take you up on
it. I hope that one of the other developers will. At the same time,
though, I want to advocate (in a minor way) for less brittleness in
BDB. I want it to be possible to access a BDB database from a Red Hat
Linux process, reboot the machine to Windows, and access the very same
database from a windows process. I want it to be possible to use
different 4.x versions of BDB against the same database. I want a
process to be able to terminate without closing its cursors and not have
the database slowly leak locks until it requires recovery. I want a
process to be able to terminate uncleanly without the database requiring
recovery.
Some of these things may be technically impossible due to other
constraints on BDB. Some of them may simply be financially infeasible.
I just want to note that there's a user (though not a paying customer)
who wants these things.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 13 17:39:46 2004