On Dec 4, 2006, at 12:03 PM, Tony Nelson wrote:
Don't allow more than one RPM client to run at a time. Especially
don't
/schedule/ two to run at the same time. OK, thanks.
Well that's perhaps overly strict.
All I'm really trying to say is that more players in the rpmdb
concurrency mix impose
stricter demands on the implementation which is already hard to debug.
cron started programs can lead to surprises.
And there is no reason why I know of why all this debugging and
fixing and testing
and verifying of an rpmdb needs to be done with "production" users.
One should approach "production" deployments carefully and
conservatively,
not just throw some change into rawhide and assume "works".
By all means try and run multiple RPM clients, and test the
concurrency thoroughly.
Just not on every user's FC6 box until thoroughly tested elsewhere.
AFAIK, read concurrency is well tested since RHL9, and write
serialization within
a concurrency environment is mostly well tested (there's an
additional fcntl lock
taken to ensure write serialization Just In Case).
The implicit assumption in the above is that a database environment
exists continuously
through process executions. All that the Berkeley DB locks in a
concurrent access model
guarantee is "multiple readers or single writer".
The new wrinkle introduced by the "del ts" in yum is re-establishing
a database environment
several orders of magnitude more often than previously. And that
"mostly works" afaict, or
all rpmdb's would have suffered total meltdown by now.
73 de Jeff
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
