Patrick W. Barnes wrote:
On Thursday 31 August 2006 14:07, Richard Hally <rhally@xxxxxxxxxxxxxx> wrote:
Matthew Miller wrote:
On Thu, Aug 31, 2006 at 01:32:05PM -0400, Bill Nottingham wrote:
transaction != atomic transaction.
Please allow 4 to 6 weeks for package delivery.
And, bizarrely, be prepared to end up with duplicate packages if there's
a shipping problem.
and if you are not there to take delivery we will just dump it on your
driveway and you will have to spread it on your garden yourself. (wink)
But seriously, without being too pedantic about it, "atomic transaction"
could be considered redundant. In database terms, a "transaction" can be
applied or rolled back and the integrity of the database is preserved in
either case. The smaller the "transaction" size the easier it is to
preserve the database integrity.
Aw, never mind. We can just use that script on the yum hints page in the
wiki.
Going further on the database terms, most of the work you do on a transaction
is *preparing* the transaction. Once the transaction is *ready*, you have a
final opportunity to cancel the transaction before you *commit* the
transaction. The commit stage is where the real work of the transaction is
done, and it is the one stage that you don't want to interrupt. When you
decide to cancel a transaction after the commit stage has begun, you must
wait until it is done and then prepare a new transaction to roll the previous
one back, or there's no telling what sort of condition the database will be
left in. In a typical RDBMS, you can usually prepare and commit the
reversing transaction very easily, but that's not always the case.
In yum, the stages of downloading the headers, calculating the dependencies,
and retrieving the packages are all part of preparing the transaction. Once
the packages are downloaded, the transaction is ready and yum begins to
commit the transaction. Just like in a database, you do not want to kill yum
while the transaction is being committed. You can cancel it beforehand, you
can roll it back afterwards, but you shouldn't be interrupting it.
Yes to all of the above.
The thing I'm trying to get across is that "the Transaction" should be
multiple *smaller* transactions so that if one of them fails the others
will not be affected.
Think of the case where there are say 64 packages to be updated. After
all the downloading, all ~128 operations are packed into *one*
transaction such that there are 64 update operations *followed* by the
64 cleanup operations. Suppose yum seg faults on the second cleanup
operation the remaining 62 cleanup operations do not happen! Leaving the
well known "rawhide baby-eater" of many half-updated packages. Simply
rerunning yum does not pickup where it failed. (as it does during the
download/preparation phase)
If you were to separate the list of packages to be updated into multiple
smaller transactions so that package A would have its cleanup operation
follow its update operation and then the next *transaction* would update
and cleanup the next package, one transaction would not affect the other.
Of course, dependencies would have to be accommodated by including them
in the proper transaction. But that would still allow unrelated
packages to be in separate "transactions."
HTH
Richard
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
