Hi Sergei,
Thanks for the quick answer. I understand that 5.1 is too far along
for this kind of change. No problem! :)
But it would be great if the commit was moved to after the unlocks.
As you say, one advantage of this would be that an engine would no
longer have to count the lock/unlocks.
At the moment I have to delay commit or rollback until after the
unlocks (i.e. when my lock count goes to zero), because I need to
flush the tables, in the context of the table handler, before I
commit or rollback.
The result is that the engine_commit() call practically just returns
OK, which means that MySQL does not get the information about
possible commit failure that it actually requires. This would be even
more of a problem in the context of XA support.
If thats OK with you, I will file a bug report on this subject.
Best regards,
Paul
On Mar 29, 2007, at 12:18 PM, Sergei Golubchik wrote:
> Hi!
>
> On Mar 29, Paul McCullagh wrote:
>> Hi All,
>>
>> I have a question regarding the order in which external_lock,
>> engine_commit and external_lock(UNLOCK) are called.
>>
>> When in auto-commit mode, the sequence is as follows:
>>
>> virtual int ha_pbxt::external_lock(THD*, lock_type=3) -- Here the
>> engine automatically does a BEGIN
>> ....
>> int engine_commit(handlerton*, THD*, bool) -- This is the transaction
>> commit.
>> virtual int ha_pbxt::external_lock(THD*, lock_type=UNLOCK)
>>
>> When in non-auto-commit mode, the sequence is as follows:
>>
>> virtual int ha_pbxt::external_lock(THD*, lock_type=3) -- Here the
>> engine automatically does a BEGIN
>> ....
>> int engine_commit(handlerton*, THD*, all=0) -- This is the statement
>> commit.
>> virtual int ha_pbxt::external_lock(THD*, lock_type=UNLOCK)
>> ....
>> int engine_commit(handlerton*, THD*, all=1) -- This is the
>> transaction commit.
>
> The logic was - if a transaction can span many statements (no
> autocommit)
> it'll be ended explicitly (COMMIT or ROLLBACK). In the autocommit mode
> storage engines commit automatically - they count the number of open
> tables and when it goes down to zero, the transaction is auto-
> committed.
> This happens for read-only statements e.g. SELECT. For DML stamements
> MySQL commits a transaction explictly to know whether commit
> succeeded.
>
> This all started from BDB handler, and others were copying from it.
>
> Yes, I think it should be changed, we should remove the "lock
> counting"
> requirement (it could be an option, of course) - then the code
> could be
> made more uniform, and commit could be moved to happen after
> external_lock().
>
> But I don't believe it could be done now in 5.1 :(
>
> Regards / Mit vielen Grüssen,
> Sergei
>
> --
> __ ___ ___ ____ __
> / |/ /_ __/ __/ __ \/ / Sergei Golubchik <serg@stripped>
> / /|_/ / // /\ \/ /_/ / /__ Senior Software Developer
> /_/ /_/\_, /___/\___\_\___/ MySQL GmbH, Radlkoferstr. 2, D-81373
> München
> <___/ Geschäftsführer: Hans von Bell, Kaj Arnö - HRB
> München 162140
>
> --
> MySQL Internals Mailing List
> For list archives: http://lists.mysql.com/internals
> To unsubscribe: http://lists.mysql.com/internals?
> unsub=paul.mccullagh@stripped
>
