[MTOS-dev] Making MT Transaction Safe

Hirotaka Ogawa hirotaka.ogawa at gmail.com
Thu Mar 13 03:54:50 PDT 2008


On Thu, Mar 13, 2008 at 6:59 PM, Alvar Freude <alvar at a-blast.org> wrote:
> Hi,
>
>  -- Hirotaka Ogawa <hirotaka.ogawa at gmail.com> wrote:
>
>
> > 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.
>
>  hmmm, something in mt_blog gets *updated*?
>  All columns look to me to be read only while rebuilding.

Sorry, that was my misunderstanding.  However, at least that is true
of MT::App::Trackback.  This application always updates mt_blog and
then rebuilds files, doesn't it?

I think that this is for invalidating smarty cache for dynamic
publishing.  If so, I can't understand why such updates are required
even if not using dynamic publishing, and why they are not required
when commenting.  Or they could be removed?

Anyway, we have to make sure there're no block-able writes (except
writes for session handling), if we are willing to employ, what I say,
giant transaction manner.

>  I looked in a SQL log of a complete rebuild (small test blog): the only
>  updates are two (!) updates of mt_session and session_start is updated.
>
>  And usually the session MUST be locked during a request, otherwise there
>  may be a lot of problems (and therefore e.g. Apache::Session::Postgres
>  makes a SELECT ... FOR UPDATE). MT does only a simple select, this might
>  result in broken session data.

Right.

>  For long running queries there might be another session handling with no
>  blocking.
>
>
>
>
>
>  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/


More information about the MTOS-dev mailing list