Adam wrote:

>
>
> Agreed, I suppose the dedicated GC thread in the SS model could be a
> best of both worlds approach, allowing the transaction to end
> immediately but hopefully it will be cleaned up by the GC thread
> rather than delaying the innocent transaction.

That turned out to be a serious problem for highly loaded systems
because the garbage collector was unable to do any significant quantum
of work in its quantum of time. The worst case was removing duplicate
index entries in indexes with >40,000 instances of a particular key
value. The gc thread went to 100% cpu and the system stopped.

>> Since the mechanism existed, Borland decided in the interest of
>>"fairness" that every transaction should carry an undo log and, if
>>possible, undo its own changes on failure. They chose to burden every
>>transaction with the potential of significant memory usage to avoid
>>cooperative cleanup in the (relatively rare) case of failure.
>
>
> Should this not be "... to avoid cooperative cleanup in all but the
> (relatively rare) case of failure." Isn't a hard disconnection etc the
> only case where roll back logs can't be processed?

What I meant is that transactions that do updates and rollback are
relatively rare. It's more efficient (in my experience) to handle that
case cooperatively - meaning unfairly because the burden of removing the
detritus falls on another transaction - is less than requiring every
transaction to maintain an undo log.

>>
>>[Considerable grumbling about the efficiency of building up a large
>>in-memory structure then dropping it has been suppressed]
>>
> LOL, any rollback operation is going to be less efficient than not
> doing it in the first place.

My problem is that you're burdening every transaction with building the
log. Even in a system that never ever has any transaction rollback
you're building undo logs. The beauty of the cooperative scheme is that
rollback only hurts if it happens. The current scheme is spending a lot
for a little bit of insurance.

>

Regards,


Ann