| Subject | Odp: Re[2]: [firebird-support] Readcomitted Read Only Transaction - Commit or Rollback? |
|---|---|
| Author | liviuslivius@poczta.onet.pl |
| Post date | 2014-02-27T16:02:12Z |
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
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
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" <kdv@...>
Do: <firebird-support@yahoogroups.com>
Temat: Re[2]: [firebird-support] Readcomitted ReadOnly Transaction - Commit or Rollback?
Data: czw., lut 27, 2014 11:36
Od: "Dmitry Kuzmenko" <kdv@...>
Do: <firebird-support@yahoogroups.com>
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 leastRJ> I assume the transaction inventory page(s) gets written multiple times for a transaction?
>> header page and transaction inventory page (s). The exception is
>> read-only database.
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