[MTOS-dev] Making MT Transaction Safe

[Hirotaka Ogawa]

On Wed, Mar 12, 2008 at 3:52 AM, Alvar Freude <alvar at a-blast.org> wrote:
> Hi,
>
>  -- Hirotaka Ogawa <hirotaka.ogawa at gmail.com> wrote:
>
>
>
> > As far as I tried this before, transactions could become too large
>  > when rebuilding lots of files.  That is, concurrency could be
>  > sacrificed in case one thread acquires such a giant lock.
>
>  with PostgreSQL and AFAIK also with InnoDB there is only a write lock on
>  each row which is changed. So, reading such a row (the old one, because
>  isolation level "read committed"!) is possible, only concurret writes to
>  the same row in the same tabele are locked.
>
>  <http://www.postgresql.org/docs/8.3/static/mvcc-intro.html>

At almost every invocations, MT::App touches the same row of mt_blog
table, and then rebuilds files, and finally commits.  In such case, I
think, other threads are blocked until the previous commit finished.

>  > Especially in SQLite, when one thread acquire a write lock (an
>  > exclusive lock), no other threads can write to any tables in a whole
>  > database file.  In such a situation, threads can easily starve.
>
>  yes, for SQLite there is an axclusive lock, but SQLite is only used for
>  testing on small databases not for real big things, or does someone use
>  it for real big blogs?

Yes. I mentioned that, only a small blog is enough to kill SQLite, if
such a naive transaction employed.

>
>
>
>
>  Ciao
>   Alvar
>
>  --
>  ** Alvar C.H. Freude, http://alvar.a-blast.org/
>  ** http://www.assoziations-blaster.de/
>  ** http://www.wen-waehlen.de/
>  ** http://odem.org/
>



-- 
Hirotaka Ogawa makes no sense.
http://as-is.net/blog/