Subject | Re[2]: [firebird-support] Readcomitted ReadOnly Transaction - Commit or Rollback? |
---|---|
Author | Dmitry Kuzmenko |
Post date | 2014-02-27T10:36:31Z |
Hello, Ralf!
Thursday, February 27, 2014, 2:08:00 PM, you wrote:
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
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