On Sat, 9 Sep 2006, Lamar Owen wrote: > On Tuesday 05 September 2006 22:35, R P Herrold wrote: >> This bug hinges, very much, on the non-atomic nature of >> 'hot' system updates, and the fact that the yum-needed, >> sqlite-maintianed cache of packages got munged half way >> through, to reproduce. > Sounds like a database type issue; ... That is, a filesystem > on ACID. (Atomicity, Consistency, Isolation, Durability: > the magic mantra of database management). *flashback* Acid - Berkeley - BSD -- coincidence? I think _not_. ;) *cough* Nothing so complex needed here; a simple early flock holding upon the sqlite-python verson with which the cache was created would have sufficed, in thinking about the bugreport. As to ACID, a interesting sidelight (as to MySQL, not the PostgreSQL which Lamar mentioned). It turns out that even with use of the Innodb backend engine in MySQL as we ship it in CentOS, and as inherited from the upstream PNAELV, for perfomance reasons, full ACID compliance is turned off. We found a reproducer in a project I am involved with, which forced us to dig down and at the database level, to ensure that full compliance is enabled from the initial connection on [http://www.trading-shim.org/capitals/?NEWS, July 30 release], to solve a need for transaction Isolation [http://dev.mysql.com/books/mysqlpress/mysql-tutorial/ch10.html]. As to using a database backend filesystem, with full ACID consistency enabled, I think a certain OS vendor in Redmond had to backaway from that featureset bulletpoint item in a somewhat delayed upcoming release. One had better be willing to suffer performance hit collateral damage with the present state of the implementaion art. Think of inviting a gorilla over, to use an anvil to swat a fly in the kitchen. ouch. -- Russ Herrold