Dmitry Yemanov wrote:

>"Jim Starkey" <jas@...> wrote:
>
>
>>That's a misdiagnosed bug, then. Making generators forced write is a
>>terrible performance decision, and is unnecessary.
>>
>>
>
>I was slightly imprecise, sorry. FB marks generator pages with
>CCH_MARK_SYSTEM, causing them to be flushed ASAP regardless of the
>transaction mask.
>

Even this is unnecessary. As long as the bdb holding the generator page
is has the transaction represented in its transaction mask, it will be
flushed as part of the transaction commit. Generator pages are very hot
pages and unnecessary writes ruin performance.

The ODS and access strategies are designed to be mathematically robust
as long as the rules are followed. Page write precedence is important,
but if properly handled, everything works.

I suspect the MARK_SYSTEM stuff was added to handle the system
transaction, which is more or less magic. In any case, it has nothing
to do with generators.

>Generator values must stay unique even if a transaction rolls back.
>
>
>

If the transaction successfully rolls back, this is correct. If the
system fails/stops/exits before a transaction finishes, there is always
the possibility that a generator value can be reused. But remember,
from the perspective of the database, generators are never re-used.
Under all circumstances it is impossible to detect from database state
that a generator has been re-used.

Generators aren't under transaction control for two reasons. First, it
would be prohibitively expensive to do so. Second, it is highly useful
for many applications to be able to depend on the fact that generators
are colinear with time without regard to transaction.


[Non-text portions of this message have been removed]