Obnoxio The Clown wrote:
> Lukas Barton said:
>
>> It does not, because Informix locks also previous and next row in all
>> indexes. So that the probability of locking rows that other user want to
>> read is more than zero.
>>
>
> I'm fascinated by this assertion. I guess I've just been unbelievably
> lucky all my working life.
>
See
-
http://publib.boulder.ibm.com/infoce...64%65%78%22%20
(2 per changed key value)

- http://docs.rinet.ru/InforSmes/ch15/ch15.htm ( For an index, three
more locks are necessary--one lock for the accessed row, one for the row
before the accessed row, and one for the row after the accessed row)

> -
> http://publib.boulder.ibm.com/infoce...64%65%78%22%20
> (2 per changed key value)
>

update locks..

1 lock required for an update on the row

2 required on the key if you are updating the key

so you are updating the key?

scottishpoet wrote:
> update locks..
>
> 1 lock required for an update on the row
>
> 2 required on the key if you are updating the key
>
> so you are updating the key?
>
>
>
Yep. I update indexed column.

Lukas Barton wrote:
> Obnoxio The Clown wrote:
>> Lukas Barton said:
>>
>>> It does not, because Informix locks also previous and next row in all
>>> indexes. So that the probability of locking rows that other user want to
>>> read is more than zero.
>>>
>>
>> I'm fascinated by this assertion. I guess I've just been unbelievably
>> lucky all my working life.
>>
> See
> -
> http://publib.boulder.ibm.com/infoce...64%65%78%22%20
> (2 per changed key value)

Lukas.

When you change an index key value, you need a lock for the before copy
to protect the prior key entry in the index. Otherwise, you could not
roll back. Also, you need a lock for the after image - otherwise
someone else could make the same change before you commit. These are
not adjacent key locks which went away with version 5. It does NOT lock
the previous and the next row.

Index locks are not done so much by locking a row. It is more like
locking a value.


>
> - http://docs.rinet.ru/InforSmes/ch15/ch15.htm ( For an index, three
> more locks are necessary--one lock for the accessed row, one for the row
> before the accessed row, and one for the row after the accessed row)

This information is invalid since v6. With v5, we had something called
adjacent key locking which was used to prevent someone from inserting an
index item until the transaction which may have deleted that item had
issued a commit. We changed that logic with version 6 with the addition
of a 'delete' flag as part of the index item. That's what the b-tree
cleaner is all about. We no longer lock the adjacent key.


>
>

>
> This information is invalid since v6. With v5, we had something
> called adjacent key locking which was used to prevent someone from
> inserting an index item until the transaction which may have deleted
> that item had issued a commit. We changed that logic with version 6
> with the addition of a 'delete' flag as part of the index item.
> That's what the b-tree cleaner is all about. We no longer lock the
> adjacent key.
>
Thanks for explaining me the problem.
You gave me first veritable advice on this problem.

Is that key locked for reading or only for updates?


Lukas
>
>>
>>
>
>

Lukas Barton said:
> scottishpoet wrote:
>> update locks..
>>
>> 1 lock required for an update on the row
>>
>> 2 required on the key if you are updating the key
>>
>> so you are updating the key?
>>
> Yep. I update indexed column.

At the risk of causing even more offence, I believe that to be very poor
application design.

--
Bye now,
Obnoxio

"... no bill is required as no value was provided."
-- Christine Normile

--
This message has been scanned for viruses and
dangerous content by OpenProtect(http://www.openprotect.com), and is
believed to be clean.

Lukas Barton said:
>
>>
>> This information is invalid since v6. With v5, we had something
>> called adjacent key locking which was used to prevent someone from
>> inserting an index item until the transaction which may have deleted
>> that item had issued a commit. We changed that logic with version 6
>> with the addition of a 'delete' flag as part of the index item.
>> That's what the b-tree cleaner is all about. We no longer lock the
>> adjacent key.
>>
> Thanks for explaining me the problem.
> You gave me first veritable advice on this problem.

Not really, it's in the manual.

If you read it. |

--
Bye now,
Obnoxio

"... no bill is required as no value was provided."
-- Christine Normile

--
This message has been scanned for viruses and
dangerous content by OpenProtect(http://www.openprotect.com), and is
believed to be clean.

Obnoxio The Clown wrote:
> Lukas Barton said:
>
>> Thanks for explaining me the problem.
>> You gave me first veritable advice on this problem.
>>
>
> Not really, it's in the manual.
>
> If you read it. |
>
Can you please post me url where could I found this?
I've read: Administrator's Guide, Database Design and Implementation
Guide, Guide to SQL - Syntax, Installation Guide for Microsoft Windows,
JDBC Driver Programmer's Guide. And I also searched infocenter and
google ;-)

Lukas

Obnoxio The Clown wrote:
> Lukas Barton said:
>
>> scottishpoet wrote:
>>
>>> update locks..
>>>
>>> 1 lock required for an update on the row
>>>
>>> 2 required on the key if you are updating the key
>>>
>>> so you are updating the key?
>>>
>>>
>> Yep. I update indexed column.
>>
>
> At the risk of causing even more offence, I believe that to be very poor
> application design.
>
You mean that updating indexed column is poor design?
You don't use indexed fields to hold some value (incl. foreing keys)?

Lukas Barton said:
> Obnoxio The Clown wrote:
>> Lukas Barton said:
>>
>>> Thanks for explaining me the problem.
>>> You gave me first veritable advice on this problem.
>>>
>>
>> Not really, it's in the manual.
>>
>> If you read it. |
>>
> Can you please post me url where could I found this?
> I've read: Administrator's Guide, Database Design and Implementation
> Guide, Guide to SQL - Syntax, Installation Guide for Microsoft Windows,
> JDBC Driver Programmer's Guide. And I also searched infocenter and
> google ;-)

I don't know. I (rather famously) don't read manuals.

--
Bye now,
Obnoxio

"... no bill is required as no value was provided."
-- Christine Normile

--
This message has been scanned for viruses and
dangerous content by OpenProtect(http://www.openprotect.com), and is
believed to be clean.