Thank you for your reply summary; i will activate this while update to mysql 5.5 on production machine, this time i'm on holiday :-)
waiting for first bugfix-release 5.5.9 to be not early-adopter some tests inserting thounsands of messages on my local testserver over imap showing that it runs very very stable and fast, even with way to small buffer_pool I think middle/end of jan wie can upgrade mysql nice, the performance-boost will be good for dbmail-3.0 migration which hopefully makes no troubles at all > Postgresql already runs in read-committed by default. So it is most > likely safe to use that for mysql as well. in this case there should be no problem since dbmail works also with postgresql fine afaik > 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. more than hundret clients on the same mailbox? sounds impossible > Let us know your results if you test this. as said my local tests with 5.5 and transaction-isolation=READ-COMMITTED are running really fine, because of too few background-know-how of dbmail i liked to make sure that you do not shout "it makes real troubles if concurrent sessions are starting" > 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. -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
