Ilja Booij <[EMAIL PROTECTED]> said: > Thomas Mueller wrote: > > Hi Ilja, > > > > [.. transactions ..] > > > >>>>It's really a matter of design, and not just something we can slap on > >>>>DBMail. We *should* think hard about how to do this in the best way > >>>>possible, but we *must* eventually move to a system that uses the > >>>>database features in a better way. > > > > > > After user complaints that dbmail is much slower than Cyrus for > > operations with lot of mails (p.e. move 200 mails to another mailbox or > > expunge a folder with lots of deleted mails) I thought about that a bit > > more. > > > > Shouldn't dbmail be a perfect candidate for an easy switch to using > > transactions? We have a defined entry and exit point for every order (the > > connection) - we don't have 100 places where dbmail can simply bail out > > with exit(something) I think? > > > > We have two classes of programs: > > - lmtpd, smtpd, pop3d: before we do anything with a message BEGIN, if we > > return SUCCESS to the client COMMIT, else ROLLBACK - should be quite > > easy? > > - imapd: for every IMAP operation: > > - if it's a read only one leave everything as it is > > - if it's a rw one BEGIN, if we return SUCCESS to the client COMMIT, > > else ROLLBACK > > > > But probably I miss something and it's much harder to code? > > You might be right. Yes, I guess you are.. Unless I'm also overlooking > something. > > Ilja
A failed delivery response from the LMTP or SMTP processes doesn't necessarily mean that nothing was inserted or updated in the database. Only a hard database error / inconsistency should generate a rollback; for all other cases, I would suggest simply commit it, even if nothing much was done. Just a simple pair of functions, db_begin() and db_commit() should suffice. Call one near the top of any database calls and the other after the end. For example, in LMTP, the calls would be at the top and bottom of the DATA case of the main switch statement in lmtp.c Aaron --
