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. -- Patrick "The N-Man" Barnes nman64@xxxxxxxxx http://www.n-man.com/ LinkedIn: http://www.linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ --
Attachment:
pgpIrttmwKceq.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
