|Subject||Re: [Firebird-Architect] Group Commits|
> Yes, with this design, that's true. Under what circumstancesNot everything is driven by human interaction (or at least not
> would this be a problem? Most applications use a transaction
> in conjunction with a human interaction, and for human's,
> 200 ms is literally a blink of the eye. What kinds of
> applications depend on single thread transaction rate (say,
> other than badly structured benchmarks)? Group commits could
> always be turned off, but maybe there's something smarter we
> could do if we had a better understanding of the problem.
every step of a process).
A couple of thoughts...
- DDL scripts (with AUTODDL turned on)
- batch processes that may be trying to commit each item
(Batch processes may commit each item for various reasons, eg:
the size of the batch is unknown so commit may be done at each
item to ensure transactions dont run too long.)
- automation based on mechanistic input events, such as a
database that commits individual meter readings
Each of these can be seen as a reason to have group commit
control at the transaction tpb level. The performance "boost"
of group commits should be able to be explicitly turned off
while there is activity that depends on immediate commit (even
if that is at the expense of others).
In most instances such activities are of limited duration, so
a server or database level of control is too coarse.