"Jim Starkey" <jas@...> wrote:

>
> For readonly transactions (transaction that perform no primary update
> pages), there is no reason to force either the header or transaction
> inventory pages to disk. They'll get written sooner or later (or maybe
> never), but this doesn't make any difference. A readonly transaction
> can safely piggyback on a later readwrite transaction. It would be
> nice, however, to eventually flush any secondary updates pages.

A read-only transaction can modify a generator value which requires an
immediate page write. If generator page writes are made defered, then they
should have precedence over all data/index pages.

> The obvious solution to group commits is a commit thread that
> periodically wakes up, checks for transactions pending completion,
> updates the header page if dirty, flushes dirty pages belonging to
> transactions pending commit, then updates the tip. All pending
> transactions are then committed. A plausible commit cycle would be four
> or five times a second, but would, of course, be settable by
> configuration file. Lets call it five times a second for discussion.

It means a defered cache page flushing, correct? I.e.
isc_commit_transaction() returns immediately although the data was not
actually written yet? I.e. it introduces the same level of reliability (or
lack of it) as the asynchronous writes, but preserves the careful write
order and require less page writes? I mean a time interval for the data of
the committed transactions to be lost in the case of failure.

Or did I miss you proposal completely?

> The scheme means that the header and tip pages would be written at most
> 5 times a second without regard to the number of transaction that
> transpire. The scheme reduces both the header and tip hot spots as well
> as any operational hot pages (index, generators, reads used as locks,
> etc) by reducing page changes by many transactions to single physical
> write per page.

How does it correspond to the FW setting? Does it make sense for the
synchronous writes only?

> The scheme seems to work equally well in superserver, classes, and mixed
> environments.

Won't it introduce 1/5 sec delays in classic? A transaction is committed,
but a concurrent process cannot read its data immediately?

> It seems so simple and obvious I can't imagine why it hasn't been done.

Done by Charlie in IB 7.5.


Dmitry