Hi Joe, http://dev.mysql.com/doc/mysql/en/ansi-diff-transactions.html
This is good read, my point is that the choice to use either MyISAM or INNODB tables depends on how the james application code (of which I am not aware in this case) is implemented. > >If anyone asks you if you glass is half empty or half full, tell them you > >design software so your glass is never empty and always filling. What I mean by this is that there is no right or wrong in software design, its all about what is more or less appropriate for a particular context. Regards, Simon ----- Original Message ----- From: "Joe Cheng" <[EMAIL PROTECTED]> To: "James Developers List" <server-dev@james.apache.org> Sent: Tuesday, June 28, 2005 4:45 AM Subject: Re: Innodb better? > Hi Simon, > > Simon Funnell wrote: > > >In the case of hardware failure, no database on this planet can 'guarantee' > >there will be no corruption, if you have a single point of failure, and it > >fails, everything fails, hence the term single as opposed to many points of > >failure. > > > > > Of course, it's not reasonable to expect a database to guarantee data > integrity if the hard drive fails, or if the filesystem itself is > susceptible to corruption (like FAT, ext2). > > However, MyISAM tables can corrupt if the mysql process is merely killed > during a write, or the power is cut off. Any decent > logging/journaling[1] persistence strategy will protect you from > these--there's no reason in the year 2005 for this to be a point of > failure at all. InnoDB for example should not suffer from this problem, > if it does then the MySQL folks *really* have no clue what they are doing. > > [1] If you're not familiar with the mechanics of journaling, see Chapter > 7 of: > http://www.nobius.org/~dbg/practical-file-system-design.pdf > > >One of the most important things about software design, in any area, is the > >concept of maximisation and minimisation. > > > >For example, in this case you can only minimise the chance of corruption, or > >maximise the chance the of recovery, or both. > > > > > My understanding is that InnoDB is (far) less likely than MyISAM to > corrupt and easier to recover if it does. So a vote for MyISAM is > really a vote for speed at the expense of safety. My question is > whether MyISAM is a reasonable default for an enterprise mail server--or > any mail server at all. > > >Obviously, having both sides of the story present will reveal a fuller > >picture, its called the art of abstraction. > > > >If anyone asks you if you glass is half empty or half full, tell them you > >design software so your glass is never empty and always filling. > > > > > Whoa, now you lost me... :) > > >Simon > > > > > >----- Original Message ----- > >From: "Joe Cheng" <[EMAIL PROTECTED]> > >To: "James Developers List" <server-dev@james.apache.org> > >Sent: Tuesday, June 28, 2005 12:27 AM > >Subject: Re: Innodb better? > > > > > > > > > >>http://dev.mysql.com/doc/mysql/en/corrupted-myisam-tables.html > >> > >>According to this link, killing mysqld or turning off the computer in > >>mid-write could result in table corruption with MyISAM. Not too > >>surprising considering it doesn't support transactions. I personally > >>would find this completely unacceptable for an "enterprise" e-mail server. > >> > >>Doesn't this terrify everyone else, and if not, why not?? > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > >>-- > >>No virus found in this incoming message. > >>Checked by AVG Anti-Virus. > >>Version: 7.0.323 / Virus Database: 267.8.1/28 - Release Date: 24/06/2005 > >> > >> > >> > >> > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.323 / Virus Database: 267.8.1/28 - Release Date: 24/06/2005 > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
