We could go down a whole can of worms here, but perhaps an answer is to
refactor sqlResources.xml into separate files for each database, where there
ARE special operations for that database, and use XML entities to include
them. That way, we can provide two different files for MySQL. Or for any
o
|
| cc:
On 6/28/05, Vincenzo Gianferrari Pini
<[EMAIL PROTECTED]> wrote:
> 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).
MyISAM does not supp
Just to help make things clear, here are some snippets from the MySql
documentation:
[...]
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. [...
On 6/28/05, Serge Knystautas <[EMAIL PROTECTED]> wrote:
> Incidentally, you can control the flush rules for InnoDB, which is
> what I've done for my James install. I only found this from listening
> to the Top 5 Performance Tips webinar, not from the docs. You can
> either have it:
> - flush from
On 6/28/05, Joe Cheng <[EMAIL PROTECTED]> wrote:
> I said *if* InnoDB is a journaling database that doesn't protect you
> against crashes, then they don't know what they're doing. The very
> point of journaling is to protect against this exact problem.
Agreed.
Incidentally, you can control the f
Stefano Bagnara wrote:
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
On 6/28/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> I will try InnoDB because of the row level locking: I think this feature
> could improve james spooling performance but I'm not sure.
Thank you. I've only been using mysql for about 2 years but other
databases before that, and row-locking s
> 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 fo
gt;
To: "James Developers List"
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 ha
inal Message -
From: "Joe Cheng" <[EMAIL PROTECTED]>
To: "James Developers List"
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
&
re 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"
Sent: Tuesday, June 28, 2005 12:27 AM
Subject: Re: Innodb better?
http://dev.
ction.
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.
Simon
- Original Message -
From: "Joe Cheng" <[EMAIL PROTECTED]>
To: "James Developers List"
Sent: Tuesday, June 2
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
TECTED]>
>Reply-To: Serge Knystautas <[EMAIL PROTECTED]>
>To: server-dev@james.apache.org
>Subject: Innodb better?
>
>
>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
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 loc
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.
17 matches
Mail list logo
