Olav Sandstaa wrote:
>>>> Yes, I agree that this code will have to be extended if/when there
>>>> can be "available" transaction objects in the (beginning of) the
>>>> list. The problem with this is that it increases the cost of
>>>> finding the "oldest active". Jim's original proposal was to have
>>>> the active list sorted with the oldest active at the front of the
>>>> list.
>>>>
>>>> Today I have implemented a patch for what I suggested in the email
>>>> I sent yesterday (as described above). Basically, I have moved the
>>>> call to TransactionManager::purgeTransactions() from being called
>>>> by the scavenger to being called by Transaction::commit(). The two
>>>> main reasons for this. The first is to call
>>>> Transaction::commitRecords() and delete old transaction commits
>>>> much earlier than when using the scavenger for this. The second
>>>> reason is that in Transaction::commit() we anyway have the
>>>> necessary locks set on the active and committed transaction lists.
>>>> The cost of this strategy will be slightly more costly than having
>>>> this done as a "batch" by the scavenger but we will free up memory
>>>> used for records and transaction objects much earlier. And if we
>>>> have to do a search for the oldest active in the active list this
>>>> will further increase the cost slightly.
>>>
>>> I just committed this patch. It moves the call to
>>> TransactionManager::purgeTransactions() from being called by the
>>> scavenger to being called by Transaction::commit(). So instead of
>>> the scavenger doing "batch" processing of this job it is now done on
>>> every commit (soon: only by non-read-only transactions).
>>
>> When TransactionManager::purgeTransactions() is called only part of
>> the time in Transaction::commit(), We may need to keep calling
>> TransactionManager::purgeTransactions() in the scavenger as a backup.
>>
>> Imagine a phase of really high load of selects with no writes
>> happening. It would be good for the scavenger to finish up purging
>> whatever transactions did not get purged by the last update
>> transaction commit.
>>
>> I don't think it hurts to have the scavenger call
>> TransactionManager::purgeTransactions().
>
>
> I agree with you that it does not hurt to have the scavenger call
> TransactionManager::purgeTransactions and that this can in some cases
> as the example you mentioned clean up some transactions that otherwise
> would hang around for a long time.
>
> I will update the patch to let the scavenger still call
> Transaction::purgeTransactions so that it implements 1 and 3 (see
> below).
>
I have committed an updated version of this patch where
Transaction::commit() and purging of old committed
transactions objects are done by:
-Transaction::commit() each time a (non-read-only) transaction commits
-The scavenger.
The patch is available here:
http://lists.mysql.com/commits/60881
Olav
