On Tue, 2009-03-17 at 10:46 +0100, Thomas Bellman wrote: > Brice Figureau wrote: > > > That's a concurrency issue, IMHO. > > If you have several hosts checking in at the same time, they both starts > > a new isolated sql transaction, they both want to write the same fact > > names because the tables are empty. You end up with as many identical > > fact_names as there were concurrent host checking in their config. > > > I thought about this issue a couple of weeks ago, but I couldn't find > > any solution to this issue, except running a fix up script that merges > > everything afterward (see ext/dbfix.sql in 0.24.8RC1). > > While I don't know much about storeconfig, it sounds to me like you should > read up on the database concept of transactions.
I don't think it will be necessary, but thanks for the suggestion :-) > With a little bit of care, > it will be impossible for one database client to do an insert inbetween > another client doing a select to find the table empty and inserting data. I think that's where you're wrong. Most RDBMS run in REPEATABLE READ isolation mode, which means the selects they are doing while in a transaction returns the data as it was before the transaction started. Hence the following scenario, involving the following two clients A and B: 1. fresh start, nothing in fact_names table 2. A: starts transaction 3. A: reads fact_names, oh, there is nothing 4. A: inserts one fact_names (say ipaddress) 5. B: starts transaction 6. B: reads fact_names, it won't read what A stored since A's transaction still isn't committed 7. A: commit, fact_names contains "ipaddress" from A 8. B: inserts the ipadress fact_names 9. B: commits 10. table fact_names contains 2 identical records. The only way to have a unique record is to run your RDBMS in SERIALIZED mode, which is a real killer for concurrency (hence why vendors ships with REPEATABLE READs by default). > Also (without knowing the database schema for storeconfig), if there is > only supposed to be one row for each value of param_name.name or > fact_name.name > in the database, then you should probably set up a unique index for those > columns, so the database will prevent you from getting it wrong. Yes, that's what I initially wanted to do (I even have a patch for this), until I realized that the aforementioned scenario was perfectly valid, and that the second transaction would then failed at commit time. This would involves some puppet code change to restart the transaction on failure. > (And yes, I know that MySQL with MyISAM tables doesn't support transactions. > That's not a problem; even if you want to use MySQL, just tell it to use > Innodb.) I was talking explicitely about InnoDB. -- Brice Figureau My Blog: http://www.masterzen.fr/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
