Andreas Korneliussen wrote:
> Mike Matrigali wrote:
>
>> I was not aware of the alter table dependency check for offline
>> compress, this must be outside of store somehow - maybe something
>> tied to all alter table statements. It may make sense
>> to change online compress to hook up with whatever offline compress
>> is doing to make this happen.
>>
>> Just testing the current system does not mean that future changes
>> won't break SUR. Unless we agree to change the contract on unlocked
>> RowLocations, then it still isn't right for code to depend on
>> an unlocked RowLocation not ever pointing to the wrong row - because
>> of the issue with truncate. Some possible issues with your test
>> in the online compress case:
>
>
>
> I think you previously said:
> "
> In current access methods this could be enforced this while holding a
> easily if the table level intent
> lock requirement is added.
> I would be comfortable adding this to store contract. It
> seems reasonable and allows coordination through locking. "
>
> I therefore think it would be good if the contract said:
> * truncate and compress requires exclusive table locking
> * the truncate, purge and compress operations do not share any locks
> with user transactions
This seems fine, but may require changes to store code and inplace
compress to actually support such a contract in store. The previous
changes just documented what was already supported.
I still don't see how this helps the holdable case, I agree this helps
the non-holdable case.
>
> Are you ok with adding this to the contract ?
>
>> 1) online compress has 3 separate phases, all of which do different
>> types of locking. Some use internal transactions, which explain
>> the conflict lock. I would try the following test:
>> o autocommit off
>> o hold cursor as your example, with a next
>> o commit transaction
>> o execute in place compress now that hold cursor has released all
>> it's locks.
>>
>
> This is exactly the problem for the holdable case: truncate. After
> truncate, a Page can be recreated, and RowLocations may be reused on the
> new page. This should not be a problem for the non-holdable case, since
> we will hold the table intent lock.
>
> Andreas
>
>> Andreas Korneliussen wrote:
>>
>>> Andreas Korneliussen wrote:
>>>
>>>> Daniel John Debrunner wrote:
>>>>
>>>>> Andreas Korneliussen wrote:
>>>>>
>>>>>
>>>>>> Problem:
>>>>>> For holdable cursors, we will release the table intent lock when
>>>>>> doing
>>>>>> commit on the transaction for the cursor.
>>>>>>
>>>>>> The table intent lock, prevents the system from doing a compress
>>>>>> of the
>>>>>> table, causing all RowLocations to be invalid. In addition, it
>>>>>> prevents
>>>>>> reuse of RowLocation for deleted + purged rows.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I think this last paragraph is an incorrect assuption. The table
>>>>> intent
>>>>> lock prevents other transactions from doing a compress, but not the
>>>>> transaction holding the lock.
>>>>>
>>>>
>>>
>>> It seems to me that that online compress will not use the same
>>> transaction:
>>>
>>> ij> autocommit off;
>>> ij> get cursor c1 as 'select * from t1 for update';
>>> ij> call SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP','T1', 1, 1, 1);
>>> ERROR 40XL1: A lock could not be obtained within the time requested
>>> ij> rollback;
>>>
>>>
>>> Offline compress is rejected if executed from the same connection:
>>> ij> get cursor c1 as 'select * from t1 for update';
>>> ij> next c1;
>>> ID
>>> -----------
>>> 1
>>> ij> call SYSCS_UTIL.SYSCS_COMPRESS_TABLE('APP', 'T1', 0);
>>> ERROR 38000: The exception 'SQL Exception: Operation 'ALTER TABLE'
>>> cannot be performed on object 'T1' because there is an open ResultSet
>>> dependent on that object.' was thrown while evaluating an expression.
>>> ERROR X0X95: Operation 'ALTER TABLE' cannot be performed on object
>>> 'T1' because there is an open ResultSet dependent on that object.
>>> ij>
>>>
>>> Are there other user-visible mechanisms to start online compress ?
>>>
>>> If not, I think we could conclude that there are no known issues with
>>> the use of RowLocation in non-holdable SUR (given the discussions
>>> about validity of RowLocation in separate threads)
>>>
>>> Andreas
>>>
>>>
>>>> That is a good point.
>>>>
>>>> The main problem would be the system doing a compress, however we
>>>> should take into account the fact that the user can run compress
>>>> from the same transaction, and then maybe invalidate the resultset,
>>>> or prevent the compress from running.
>>>>
>>>>> I think there are other situations where the RowLocation will become
>>>>> invalid, such as the transaction deleteing the row.
>>>>>
>>>>
>>>> Yes, however as far as I understood, the RowLocation would not be
>>>> reused as long as at least some sort of table level intent lock is
>>>> held, and the store will simply return false if one tries to do
>>>> update / delete / fetch on a RowLocation which is deleted, or
>>>> deleted+purged.
>>>>
>>>> Andreas
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
>
|