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

>
> However, a change to a generator is performed with a simple mark (no
> force-write). This is safe because the generator page will always be
> flushed before a transaction is committed.

It's performed with a force-write mark since FB 1.5.1. A generator page
could be actually flushed after the transaction data. There were a number of
bugreports regarding this case recently - after a server crash the existing
PK identifiers were generated, because the generator page was not flushed
properly.

> In any case, a generator is only guaranteed unique if the transaction
> commits.

I'm not sure I get you here. Generators are outside the transaction context,
so they should be guaranteed unique regardless of the commits.

> >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.
>
> The transaction would not be reported committed until after the
> transaction has been committed.

Then your group commits differ from Charlie's ones ;-) And I'm afraid I miss
something important in your proposal.

If a group commit thread is waked up 5 times per second to flush the
modified pages of the transactions being committed, it means that either
every commit waits for t <= 0.2 seconds or commits are async/defered. If
every commit notifies a group commit thread and waits for it to do its job,
then I fail to see both "five times a second" and a "group" here. Perhaps,
tomorrow my brain will work properly and I'll understand your proposal. If
you'll have a few minutes to forward me in the necessary direction, it would
be much appreciated.


Dmitry