james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincenzo Gianferrari Pini <vincenzo.gianferrarip...@praxis.it>
Subject Re: Innodb better?
Date Tue, 28 Jun 2005 20:26:23 GMT
Just to help make things clear, here are some snippets from the MySql 


    MySQL Server (version 3.23-max and all versions 4.0 and above)
    supports transactions with the |InnoDB| and |BDB| transactional
    storage engines. |InnoDB| provides /full/ |ACID| compliance. [...]

    The other non-transactional storage engines in MySQL Server (such as
    |MyISAM|) follow a different paradigm for data integrity called
    ``atomic operations.'' In transactional terms, |MyISAM| tables
    effectively always operate in |AUTOCOMMIT=1| mode. Atomic operations
    often offer comparable integrity with higher performance.


    ``Atomic,'' in the sense that we mean it, is nothing magical. It
    only means that you can be sure that while each specific update is
    running, no other user can interfere with it, and there will never
    be an automatic rollback (which can happen with transactional tables
    if you are not very careful). MySQL Server also guarantees that
    there will not be any dirty reads.


It means that MyISAM works like having transactions containing a single 
update statement, offering row-level locking one at a time and being 
able to recover from crashes (in the worst case using myisamchk).

James for normal operations *does use transactions* (see 
org.apache.james.mailrepository.JDBCMailRepository#store(MailImpl mc)), 
but does only one update at a time. So MyISAM is perfectly appropriate 
and safe, and InnoDB row-level locking would bring no advantage. The 
real disadvantage od MyISAM is the occasional need to run *manually* the 
myisamchk utility, or setting up an appropriate startup script.

Because of such lack of automatic recovery in all situations, I feel 
much more confortable using InnoDB, but if performance is an issue 
MyISAM would perform better.

I did also setup a slave server, but just to have a second server always 
ready to run if the primary server is unable to restart, not for having 
better crash integrity. The synchronization is almost instantaneous.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message