Mike McCarty wrote:
> Hmm. I can see where actually doing an update or clean etc.
> would require locking, but why does just asking?
<snip>
> This does not appear to be an error. It appears to be a design
> decision.
Um. Probably it saves a lot in testing.
If you attempt to read a database without locking, there's no guarantee
that you won't read it just as the other process is changing something,
resulting in an inconsistent view of the database.
Getting around that inherently means locking. And that introduces the
possibility of dead-locks: where one process has a lock on part of the
structure and wants another lock, but another process already has that
lock, and wants to take out the first lock as well. Neither process can
move.
That's not exactly a healthy situation for a pretty critical database
(the RPM database) to get in. Especially since either or both yums could
be automated: the deadlock and hence the RPM transaction could last for
weeks, leaving the box with no automated updates and the RPM database
being shut down mid transaction.
There are only three ways to avoid this:
* some protocol where only one update process is allowed, and all
the others know they should give way on deadlock. This means code
to detect deadlocks, which wouldn't be tested much and hence could
hold a lot of bugs. Besides, it's not something that existing
database packages provide.
* an agreement among all users of the database that locks will be
acquired in a certain order. This is difficult to enforce with the
existence of yum plugins.
* One Big Transaction. That's what we've got...
James.
--
E-mail address: james | "We've just been contacted by the Lady of the Lake."
@westexe.demon.co.uk | "Really? What does she want?"
| "A really big towel."
| -- http://www.mopsy.com/d/19981122.html
