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 Sun, 26 Jun 2005 17:16:56 GMT
Serge,

In my understanding, InnoDB offers two major functionalities: row-level 
locking and ACID transactions.

1) Row-level locking

The only tables with lots of updates are inbox and spool, but the 
inserts and deletes are always not conflicting, so using MyIsam tables 
without table-level locking (as is by default in James) is safe (MyIsam 
"atomic" updates are always guaranteed to be safe) and should be faster 
than using InnoDB .

2) ACID transactions

Unless I'm completely wrong, in the worst case for each mail James reads 
a row from the spool table, writes it to the inbox table and deletes it 
from the spool table in the same transaction. Assuming that the order of 
events is as just said, in case of a crash or JDBC abort, if using 
MyIsam without ACID transactions and using autocommit there could be the 
very unlike risk of ending up with the mail both still in the spool and 
delivered to the inbox, but this would only imply the mail later on 
being delivered again, which is not so terrible.

I personally feel nervous if I'm using a database without transaction 
support even when not really needed, but others would not agree.

--------

Given that, and because InnoDB is not to be granted as available in a 
new James installation, IMHO it is better to leave sqlResources.xml as 
it is now. In any case, if the user wants to always use InnoDB like me 
just as a matter of principle, it is enough for him to set 
"default-table-type=innodb" in my.cnf.

Completely different is the case where a matcher or mailet issues 
updates that *must* be under the umbrella of the same transaction, as is 
for example the case of the BayesianAnalysisFeeder mailet. Because of 
that, and because Bayesian Analysis is an option, I did put 
"TYPE=InnoDB" in the sqlResources.xml CREATE TABLE statements for all 
the relevant tables.
Moreover, as the updates can be thousands for the same transaction 
during a feed, deadlocks could easily happen with row-level locking, so 
I inserted a "synchronize" in the right place so only one message at a 
time is processed. This single-threading is not a problem because the 
rate of training feeds is in any case low. The real BayesianAnalysis 
mailet instead is fully multi-threaded (synchronization occurs only when 
reloading the corpus).

Vincenzo

Serge Knystautas wrote:

>After reading some tips on mysql optimization, I altered my email
>table for James from myisam to innodb.  The rational was that there is
>a lot of concurrent writing happening, so it would greatly benefit
>from row-level locking.
>
>It seems like things are faster, though I haven't done any real tests.
> For others who know MySQL well, does this make sense, and should we
>alter the create scripts to use this table type?
>
>  
>

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


Mime
View raw message