On Thu, 2003-10-16 at 12:11, Matthew T. O'Connor wrote: > On Thu, 2003-10-16 at 11:55, Chris Mason wrote: > > There's a lot more to using transactions than BEGIN/COMMIT. The current > > code orders operations such that transactions are not purely required. > > When inserting messages it sets the unique_id last (as a kind of > > informal commit), does rollback manually when some part of the insert > > fails, etc. > > > > A real transactional system would let the database do all of that. My > > patch only addresses a performance aspect with mysql transactional > > tables...every write triggers a commit. Enclosing them in a transaction > > does one commit for the whole group instead. > > I agree with all the above 100%, my biggest gripe with the dbmail design > is that it does a lot of work to deal with mysql limitations. I think > that's a bad design decision. Use the database to do what it does best, > which is maintain data consistency for you. >
It's important to remember that non-transactional tables have their place in some workloads. They are faster and use less resources overall. So, it's not about the lowest common denominator, its about deciding which workloads you want to support. For my own personal use, I want transactional tables, but others might not. -chris
