Hi, I think about this. Is this really needed to write TIP pages back to disc if readoonly readcommited transaction start or end? I see no reason for that. But maybe i miss something ..
Regards, Karol Bieniaszewski ----- Reply message ----- Od: "Dmitry Kuzmenko" <[email protected]> Do: <[email protected]> Temat: Re[2]: [firebird-support] Readcomitted ReadOnly Transaction - Commit or Rollback? Data: czw., lut 27, 2014 11:36 Hello, Ralf! Thursday, February 27, 2014, 2:08:00 PM, you wrote: >> start and commit/rollback of any transaction will write at least >> header page and transaction inventory page (s). The exception is >> read-only database. RJ> I assume the transaction inventory page(s) gets written multiple times for a transaction? RJ> Something like setting active, setting commit/rollback, deleting from page? I don't know all the details of FB sources (I hate C/C++, sorry), but yes, when new transaction starts TIP is extended, and if it is new TIP page, so, there are more writes, than one (pointer to the next TIP page, etc). But no deleting. TIP is always increasing and updating only, because TIP stores transactions state and nothing more. And it grows up to MaxInt transactions (in FB3 - unsigned int, so, 2x more). BTW, about read-only read-committed transactions - they intended to be long, and, starting and committing lot of such transactions seems useless. If you have lot of clients that do some reading from time to time, maybe it's better to lower server load by using some middleware, which will have connection pool with long-running read_only read-committed transactions. This is just a note, of course, I don't know architecture of your system. -- Dmitry Kuzmenko, www.ib-aid.com
