Vlad Horsun wrote:

>

I wrote:

>>... for read-committed transactions. Those transactions would put a
>>minus one in the lock data for their transaction lock ...
>
> Hmm, why do you want to change behavior of current transaction lock data ?
> As i understand we agreed that "read commited write" transactions must store
> its own transaction number in its lock data (instead of found during TRA_start
> oldest active number) ?

Ah. I've thought about it some more and decided I was wrong. A
read-committed transaction should not block garbage collection at all,
except to protect blobs.

Consider this sequence

Read committed transaction 101 starts
Transaction 102 starts
Transaction 102 writes record X
Transaction 102 commits
Transaction 103 starts
Transaction 103 updates record X
Transaction 103 commits
Transaction 104 starts
Transaction 104 reads record X
????

Is there any reason why transaction 104 shouldn't remove the old record
version stored by transaction 102? Transaction 102 won't read it - it
will read the most recent committed version. Even record versions
created after a read committed transaction started can be garbage
collected without affecting running read committed transaction.

>
>>When a read-committed transaction does a commit-retaining (or rollback
>>retaining), it creates a new transaction lock block with a minus one for
>>lock data,
>
> The same question as above

Same answer.

>
>
>>but retains the lock it has in the new series.
>
> Agreed
>
>>Thus blob-ids
>>would be reliable across a commit-retaining, which makes sense to me,
>>since the general description is that a commit-retaining "retains the
>>context" of the transaction.
>
> Of course
>
>
>>We eliminate the current "pre-committed" status for read-only read
>>committed transactions - it causes "blob not found" errors.
>
> Do you want to delete "pre-committed" status from the engine ?

No, there's one very important pre-committed transaction: the system
transaction (aka Transaction Zero). Changing the semantics of that
transaction (though it might be a good idea) is going to be very messy.

>

Regards,


Ann