On 19 Nov 07, at 2139, Scott Adkins wrote: > This does bring up an important point... we had to disable duplicate > suppression on our server because it was just causing too much > contention. > When every single mail message being delivered has to check against > the > database, it is a problem. The checking's not the problem, as the 99.9% case is an update. In other words, if the rate of duplicates were high, you could lock it for reading, check the message was unique, and then if that gave a positive response lock it for update and perform the update. Yes, there's a race condition, but it's small and benign. However, in the real world this gains you nothing, because the rate of duplicates is vanishingly small. You buy complexity and a race condition for degraded performance (the lock upgrade is expensive). There are other possible solutions. One would be a per-user, or per- user-initial-letter, duplicate database. Another would be to not bother syncing the database (I think this is what berkeley-nosync does, but that doesn't help skiplist users). ian ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
