Michael Monnerie wrote: > On Mittwoch, 9. April 2008 Paul J Stevens wrote: >> This could be a race condition where two dbmail-lmtpd or dbmail-smtp >> processes try to store the same headername at the same time. >> >> Solving this type of concurrency issue is a driver for 2.3+ >> development. > > I thought about this too. A simple quick solution would be not to break > the transaction because of this, in order to make a successful > delivery. But as it's not too often, it can be ignored, I guess. What > happens to the e-mail whose transaction is aborted? Lost, or thrown > back at postfix which retries again later? Horrible would be an error > back to the sender (looks unprofessional).
Iirc, the only transaction that is broken is the cache insertion, not the message insertion perse. I've tried to solve this using two different approaches. Using savepoints and rollbacks to the savepoint on failure works great for postgres. However, mysql doesnt support savepoints in a useful fashion: it will abort the whole transaction, even when a savepoint was set. The second approach was in the trunk for a supplement for savepoint (or alternative in case of for mysql and sqlite). I had the cache insertion packed in a simple retry loop: If it fails, sleep a while, and try again. I've experimented with retry loops a lot during 2.3.0 developement, and they worked just great, but nowadays preforking is gone, libevent and libzdb ruleth, and threading is in progress. So I removed those loops for now to clean up the picture and allow me to focus on core-stability under high concurrencies. The cache insertion is now done on a connection that is pulled fresh from the pool. This means there is no longer a massive big transaction lock around the whole insertion chain. If the cache insertion fails it raises an exception. At this moment, such an exception will still abort the header caching sequence, but allowing it to continue would be trivial (by simply changing the return value from TRUE to FALSE). Once this proves to work out ok, I can re-instate the retry loop or come up with an alternative, but only if I observe deadlocks or race conditions in the code. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
