|
баг в informix или почему такое происходит???
|
|||
---|---|---|---|
#18+
Добрый день, вчера заметил вот какую вещь,что в любой таблице с любым типом lock mode при изменении 1 строки,другой пользователь не может изменить другую строку. Эксперимент: user1: CREATE TABLE t_acc( acc CHAR(18) ) LOCK MODE ROW; insert into t_acc values ("1"); insert into t_acc values ("2"); begin work; update t_acc set acc="11" where acc="1" не коммитим и не откатываем user2: update t_acc set acc="22" where acc="2" He gets the following error message: 244: Could not do a physical-order read to fetch next row. 107: ISAM error: record is locked. Это наблюдается и на 11.50 и на 11.70,так что я думаю,что это баг всех версий informix. Ведь если я создаю таблицу с lock mode row,то и блокироваться должна строка,а не так как в этом случае. Селект на вторую строку проходит нормально. Единственным выходом изменения данных является изменение строки по ее rowid, тогда все работает. Ведь так не должно быть и это неправильно или я в чем-то глубоко заблуждаюсь? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.11.2011, 11:11 |
|
баг в informix или почему такое происходит???
|
|||
---|---|---|---|
#18+
так было и будет во всех rdbms с блокировками, если нет индекса для where acc=. create index t_accx1 on t_acc(acc); ... |
|||
:
Нравится:
Не нравится:
|
|||
10.11.2011, 11:16 |
|
баг в informix или почему такое происходит???
|
|||
---|---|---|---|
#18+
Журавлев Денис, а почему с индексом начинает работать? потому что в таком случае поиск идет по индексу,а индекс использует(содержит) rowid строк,правильно? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.11.2011, 11:20 |
|
баг в informix или почему такое происходит???
|
|||
---|---|---|---|
#18+
LudeV, потому что без индекса СУБД перебирает все строки, одна из которых заблокирована другим пользователем. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.11.2011, 11:26 |
|
баг в informix или почему такое происходит???
|
|||
---|---|---|---|
#18+
потому что без индекса субд может найти строки where acc="2" только просканировав таблицу и вот на select * from t_acc where acc="2" (на самом деле не делается селект, там все уровнем ниже происходит), чтобы поставить блокировку и вылезает Could not do a physical-order read to fetch next row. потому что пытаемся прочитать заблокированную строку, которая еще с acc=1 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.11.2011, 11:30 |
|
баг в informix или почему такое происходит???
|
|||
---|---|---|---|
#18+
кстати в 11-х во второй сессии и set the IsolationLevel to ReadCommited поможет. Только лучше так не делать если нет понимания. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.11.2011, 11:40 |
|
баг в informix или почему такое происходит???
|
|||
---|---|---|---|
#18+
спасибо всем,понял а при read commited мы будем видеть только то,что уже закоммитилось, я понимаю это так. потому что если поставить dirty read,то мы сможем видеть все строки,даже те,которые сейчас меняются,поскольку о изменяемых строках данные будем брать из сегментов отката(физ журнала),так? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.11.2011, 12:16 |
|
баг в informix или почему такое происходит???
|
|||
---|---|---|---|
#18+
LudeVспасибо всем,понял а при read commited мы будем видеть только то,что уже закоммитилось, я понимаю это так. потому что если поставить dirty read,то мы сможем видеть все строки,даже те,которые сейчас меняются,поскольку о изменяемых строках данные будем брать из сегментов отката(физ журнала),так?вы все понимаете неправильно, чтобы понимать правильно надо читать документацию, а не гадать. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.11.2011, 12:22 |
|
баг в informix или почему такое происходит???
|
|||
---|---|---|---|
#18+
Журавлев Денис, понял. будем читать эту тему давайте закроем ... |
|||
:
Нравится:
Не нравится:
|
|||
10.11.2011, 12:56 |
|
баг в informix или почему такое происходит???
|
|||
---|---|---|---|
#18+
LudeVвчера заметил вот какую вещь,что в любой таблице с любым типом lock mode при изменении строки,другой пользователь не может изменить другую строку. ... Это наблюдается и на .50 и на .70,так что я думаю,что это баг всех версий informix. ... Ведь так не должно быть и это неправильно или я в чем-то глубоко заблуждаюсь? Очень похвально ваше желание разобраться в тонкостях, в попытках провести практические опыты, в стремлении освоить новый продукт и новое направление. Но, не спешите делать скоропалительные выводы (насчет багов, особенно в таких фундаментальных вещах). У вас пока нет, точнее мало, базовых знаний и от этого еще будут возникать проблемы с пониманием более сложных понятий. Чтобы сэкономить себе кучу времени на "разборки" и исправление ошибок в будущем, лучше сейчас потратить время на чтение пары книжек по Информиксу, чтобы разобраться с основными понятиями. Поверьте моему опыту тренера, это даст вам огромное удовольствие от новых открытий и понимания многих "сложных" вещей, которые довольно банальны. Список доступной литературы на русском есть в FAQ, но лучше, и полезней, просто читать документацию, она очень хорошо и подробно написана. Удачи. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.11.2011, 13:19 |
|
баг в informix или почему такое происходит???
|
|||
---|---|---|---|
#18+
LudeV... потому что если поставить dirty read,то мы сможем видеть все строки,даже те,которые сейчас меняются,поскольку о изменяемых строках данные будем брать из сегментов отката(физ журнала),так? Это неверно. При dirty read сессия читает данные, в т.ч. которые меняют другие сессии, не принимая во внимание что некоторые из них могут быть еще не подверждены (т.е. commit или rollback для них не выполнен), потому этот уровень изоляции так называется. В информиксе нет сегментов отката, физический журнал это другое. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.11.2011, 22:06 |
|
баг в informix или почему такое происходит???
|
|||
---|---|---|---|
#18+
Я вдруг вспомнил, что можно управлять ожиданием снятия блокировки: http://www.sql.ru/forum/actualthread.aspx?tid=687748&pg=1&mid=7541026 ... |
|||
:
Нравится:
Не нравится:
|
|||
11.11.2011, 16:41 |
|
|
start [/forum/topic.php?fid=44&msg=37519736&tid=1607234]: |
0ms |
get settings: |
26ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
51ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
279ms |
get tp. blocked users: |
1ms |
others: | 318ms |
total: | 708ms |
0 / 0 |