Re: [boost] ACID transactions/flushing/MySQL InnoDB

Subject: Re: [boost] ACID transactions/flushing/MySQL InnoDB
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2009-12-12 12:28:03

On Sun, Dec 13, 2009 at 1:03 AM, Stefan Strasser <strasser_at_[hidden]> wrote:
>
> Am Saturday 12 December 2009 16:47:58 schrieb Dean Michael Berris:
>
> >
> > I see. Do you have a separate index mechanism?
>
> no log index.
> the log is rolled when it reaches a certain size, so it can be read as a whole
> sequentially on restart.
>

I see.

> >
> > then putting it
> > in the beginning allows you to re-use the area after that entry
>
> the data needs to be flushed asap as the user thread is waiting for its
> recorded commit, which is part of that data.
> so reusing that area is not an option, unless you want to seek(). (you don't.)
>

Right, but I was thinking if you were packing the data in memory first
and then merging flushes then you don't need to seek on write.

> > > you could only avoid some syncs when 2 or more independent transactions
> > > run concurrently and they both need to sync, those could be combined. but
> > > that's not my focus right now.
> >
> > Alright. Thanks for indulging me and my suggestions. :)
>
> you are very welcome, you're just thinking 5 steps ahead.

:)

> if it's not improving performance by 400%, like this case did, it has to wait
> among the > 100 other optimization TODOs.
>

Alright, am looking forward to the resulting library then! :)

--
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com