Hi,
I asked a friend who is a Berkeley DB expert about these locking issues.
You can find his blog posting at www.ddanderson.com/myblog/
It starts:
I hear this occasionally - Berkeley DB is unreliable, is prone to lockups,
you just can't depend on it. On the other hand, I've been working with BDB
customers for several years creating systems that reliably run nonstop
storing and retrieving data. Some of these people test by literally pulling
the plug during a busy load cycle and making sure their system can come
back without loss of data. And they don't have lockups either. So where's
the disconnect?
Phil
Nils Kaiser <[EMAIL PROTECTED]>
> we are using a webservice to check if a user agent is a mobile or
full > browser. We have to integrate this on the root path of a site to >
redirect mobile browsers to a mobile page.
I haven't had an issue with berkeley db since 4.2 , however there are db
lock issues and general unpleasantness abound when you have a power failure
type reboot
Jeff Pang <[EMAIL PROTECTED]>
> Just give another suggestion.How about memcached?
> I think it's also a good and fast cache product.
Memcached is volatile -- power goes / reboot, you lose everything.
"Perrin Harkins" <[EMAIL PROTECTED]>
> It's slower than BerkeleyDB and Cache::FastMmap. If you need your >
cache to work across multiple machines, memcached is a good idea. For > a
single machine, there's no reason to use it.
with bdb on a single machine, you're still apt to run into time issues from
locking by competing apache children on the bdb - i'm not sure how they
would measure, but them in addition to the ridiculously small amount of
overhead any pageload would create make me thing the backend store is
negligible in the greater scheme
personally, i would do something that has the potential to scale to
multiple servers:
write to postgres + memcached
read from memcached, failover to postgres
if you wanted, you could do a bdb store locally per-machine instead of
memcached.
if you're doing bdb, you're stuck with that only working on a single webapp
machine -- unless you write a daemon to handle queries to it.
its not as fast as other solutions, but it will take the same amount of
time to code and will infinitely scale, so you only do the work 1x.
re: deployment
i think the mod_perl support on the 'enterprise linux' platforms are pretty
bad -- they're often way out of date. public distros, like ubuntu, are
usually up-to date. freebsd support is the best, much thanks to philip
porting to freebsd within minutes of the source code release (btw, freebsd
is definitely an 'enterprise level' product ) windows support is pretty good.
i'm pretty sure that the only reason why some distros have better support
for mp , is that certain companies who have multiple servers of a given OS
find it much easier to manage the port, so they can keep all their internal
stuff up-to-date.
