Hello, Helen,

>>GC should never be inhibiteded in READ COMMITTED case. Only TIP
>>cleanup may need to be inhibited, but I doubt it for retaining
>>transactions as they are marked as committed AFAIR. I may perform a
>>closer look on this code if you want.
>>
>>If what I wrote is wrong

> It's wrong and it's not a bug. CommitRetaining retains the cursors from
> the preceding transaction open and makes the transaction 'interesting"
> until a hard commit occurs.

And what ? Marking transaction as "interesting" (thus stalling OIT
counter) only slightly complicates TIP analysis before next sweep, not
affecting record versions GC. Only OAT counter or oldest snapshot
counter may affect record versions GC.

I reviewed commit-retaining algorithm right now and I do not see a
reason why should it affect GC in any way.

Commit retaining is basically a normal commit except that new
transaction is started right after COMMIT_RETAINING and committed
subtransaction number is placed into a special bitmap for newly
started transaction. This bitmap is used in VIO_chase_record_version
to determine if record should be visible or not.

BTW, if there is interest i can write and post test application
demonstrating above statements.

> You could get a gazillion "test cases". CommitRetaining is *designed* to
> work this way. It was put there by Borl to make client/server datasets
> behave like Paradox tables. It's a total crock with MVA. It's astonishing
> that JDBC should consider it a good enough thing to include as a spec.

It looks like you neither looked at the code nor tried to use this
feature. As of current, I do not see any inconsistencies neither in
this feature design nor in its implementation.

> Helen

--
Nickolay Samofatov