[MTOS-dev] Making MT Transaction Safe

[Hirotaka Ogawa]

On Tue, Mar 11, 2008 at 10:02 PM, Alvar Freude <alvar at a-blast.org> wrote:
> Hi,
>
>  -- Hirotaka Ogawa <hirotaka.ogawa at gmail.com> wrote:
>
>
> > Yep.  I've not tested, but we can do as like:
>  >
>  >     unless ($options->{nocommit}) {
>  >       eval {
>  >           $sth->execute;
>  >       };
>  >       if ($@) {
>  >           $driver->rollback;
>  >           Carp::croak("INSERT error $driver: $@");
>  >       }
>  >       $driver->commit;
>  >     } else {
>  >       $sth->execute;
>  >     }
>  >     $sth->finish;
>
>  hmmm, usual the eval is around the whole transaction, all reading queries
>  and other code included. The commit also must be inside the transaction.
>  And when something fails, PostgreSQL needs an explizit rollback to
>  enforce data integrity.
>
>  <http://search.cpan.org/~timb/DBI/DBI.pm#Transactions>
>
>
>
>  > Which is better?
>  >
>  > I think the former is better, because we can easily and explicitly see
>  > how transactions handle in MT Core.  The latter is surely easy to
>  > code, but too implicit, I guess.
>
>  Yes, I agree, the first one seems to be better (but more work).
>
>
>  But what about putting the whole HTTP request into one transaction,
>  perhaps with an extra transaction for the session?

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.

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.

>
>
>
>
>  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/