Harald, Postgresql already runs in read-committed by default. So it is most likely safe to use that for mysql as well.
DBMail currently uses only a few multi-query transactions, so this issue is moot for most people. Only on highly concurrent system will you run into isolation issues. Some of the imap synchronisation issues with high concurrencies on the *same* mailbox (clients > 100) will most likely require much stricter handling of isolation. Let us know your results if you test this. On 2011-01-03 02:34, Reindl Harald wrote: > hi at all, happy new year and thanks 3.0 RC > sounds like a real good shit to me :-) > > I found this some minutes ago because i can not sleep and so > i started google something useful, is it safe for dbmail > to set "transaction-isolation=READ-COMMITTED" or better > leace the defaults to not hurt anything? > > http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/ > >> Also check if your application can run in READ-COMMITED isolation mode – if >> it >> does – set it to be default as transaction-isolation=READ-COMMITTED. This >> option has some performance benefits, especially in locking in 5.0 and even >> more to come with MySQL 5.1 and row level replication. > > http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html#isolevel_read-committed > > A somewhat Oracle-like isolation level with respect to consistent (nonlocking) > reads: Each consistent read, even within the same transaction, sets and reads > its own fresh snapshot. See Section 13.2.8.2, “Consistent Nonlocking Reads”. > > For locking reads (SELECT with FOR UPDATE or LOCK IN SHARE MODE), InnoDB locks > only index records, not the gaps before them, and thus permits the free > insertion > of new records next to locked records. For UPDATE and DELETE statements, > locking > depends on whether the statement uses a unique index with a unique search > condition > (such as WHERE id = 100), or a range-type search condition (such as WHERE id > > 100). > For a unique index with a unique search condition, InnoDB locks only the > index record > found, not the gap before it. For range-type searches, InnoDB locks the index > range > scanned, using gap locks or next-key (gap plus index-record) locks to block > insertions > by other sessions into the gaps covered by the range. This is necessary > because > “phantom rows” must be blocked for MySQL replication and recovery to work. > -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
