If you will notice in the test I committed, there are three different
tests that showthe affect of multiple locks to the same record at
multiple savepoints. The first one is similar to falcon_deadlock but
the other two are unique.
Hakan Kuecuekyilmaz wrote:
> Other than Olav's great comments, you should consider that we already
> have a test for this bug: falcon_deadlock.test in falcon_team test
> suite. Maybe you could merge your test and falcon_deadlock.test?
>
> Cheers,
>
> Hakan
>
>
> On Do, 2009-02-12 at 20:22 +0000, Kevin Lewis wrote:
>> #At file:///C:/Work/bzr/Merge/mysql-6.0-falcon-team/ based on
> revid:kevin.lewis@stripped
>>
>> 3015 Kevin Lewis 2009-02-12
>> Bug#34182 - Falcon needs to be able to keep locks at lower savepoints when
> they are explicitly released or uinlocked at hight savepoints Locks should be retained
> during the life of that savepoint unless they are explicitely unlocked before the next
> savepoint.
>>
>> It is not necessary to add a new lock record at each savepoint. The
> existing lock will do the job as long as it is not unlocked at a later savepoint. The
> best solution to this problem is to only unlock records that were locked in the current
> savepoint, or verb.
>>
>> A new integer is sent into unlockRecords which holds the current verbMark
> or
>> savepoint. LockRecords that are at a higher savepoint are not unlocked.
> Then, if a
>> commit, rollback, releaseSavepoint, or rollbackToSavepoint occurs that
> would release that
>> lockRecord, it will get released just like it did before.
>>
>> A new testcase is added that shows the affect of locks attained at
> multiple savepoints.
>> added:
>> mysql-test/suite/falcon/r/falcon_bug_34182.result
>> mysql-test/suite/falcon/t/falcon_bug_34182.test
>> modified:
>> storage/falcon/StorageTable.cpp
>> storage/falcon/Table.cpp
>> storage/falcon/Table.h
>> storage/falcon/Transaction.cpp
>
>
>
