SYS(3052) - Override SET REPROCESS Locking
Specifies whether Visual FoxPro uses the SET REPROCESS setting when attempting to lock an index or memo file.

Порыскав по архивам, обнаружил, что сабжевая функция практически ни разу не обсуждалась ни тут (всего 1 тема, и то вскользь), ни в fido7.ru.visual.foxpro (1 тема и тоже вскользь), и ни одного на VFP-разделе форума www.sql.ru. А меж тем:

Цитата:

SYS(3052, nFileType, [lHonorReprocess])
Specifies whether Visual FoxPro uses the SET REPROCESS setting when attempting to lock an index or memo file.
.....
lHonorReprocess
Specifies whether Visual FoxPro uses the SET REPROCESS setting for unsuccessful lock attempts for index and memo files.
.....
Specify false (.F.), the default, to override the SET REPROCESS setting when Visual FoxPro attempts to lock files specified with nFileType. When set to false, Visual FoxPro waits indefinitely for locks on the specified files
.....

It's best to set lHonorReprocess to true (.T.) in order to reduce the risk of file lock contention if your application uses transaction processing.

*****
(c) Цитата из топика по SYS(3052)

Делаю вывод, что никто никогда не применял? Столько разговоров о транзакциях, блокировках, о минимизации времени бюлокировок, стратегиях минимизации риска нарваться на блокировки чужие - и при всем при этом практически ни слова о SYS(3052)...
Для тех, кто не в курсе, пару слов о том, чем именно SYS(3052) дает порулить. Пример для индексов. Вот, к примеру, решили вы скинуть изменения из буферов в источники. Вы естесственно, открываете транзакцию и оборачиваете ею сброс изменений в буферах, для того, чтобы обеспечить целостность скидывания/отката. Совершенно стандартная практика. Также широко известен следующий факт: Все измененные внутри транзакции записи до окончания транзакции остаются заблокированными. Что влечет за собой следующее: Если другой сетевой участник работы с базой попытается изменить любую из тех записей, которые вы уже изменили внутри своей еще незакрытой транзакции, то он нарвется на блокировку и его Tableupdate отвалится, при этом его AERROR() будет содержать ошибку 109 (Record is in use by another user). Однако, почему-то гораздо менее широкую известность (вернее лучше будет сказать "обсуждаемость") имеет другой факт (который ИМХО, намного более опасен). Внутри транзакции блокируются не только записи, но еще и индексы. И не просто индексы, а индексные файлы целиком, все теги за раз. Что это значит... Любое измененное внутри незакрытой транзакции поле в любой записи, входящее в расчет какого либо тега, блокирует весь индексный файл до окончания транзакции. Поэтому другой сетевой участник не сможет изменить ни одного поля ни в одной записи таблицы вообще, если это поле входит в индексное выражение любого тега CDX-файла. Он получит Record not available ... please wait. При этом получит это сообщение навечно, ибо по-умолчанию попытки получить доступ к CDX-файлу бесконечны. И самое замечательное при этом, что на попытки блокировки индекса никак не влияет установка SET REPROCESS (количество/продолжительность попыток блокирования записи). В итоге, если даже выставить SET REPROCESS TO 1 (одна попытка), то при изменении поля любой записи, входящего в выражение любого тега, мы получим "зависание" фокса на неопределенное время до тех пор, пока транзакция, заблокировавшая до нас индексный файл, не будет завершена, ибо SET REPROCESS фокс в данном случае просто игнорирует. Чем грозит, я думаю, объяснять не надо. Любой "кризис", "остановка" , зависание, модальное состояние внутри транзакции грозит серьезнейшими осложнениями в виде невозможности нормальной работы всех остальных сетевых участников базы. Конечно, известна истина, что транзакция должна занимать минимум времени, как раз-таки по причине создаваемых ею блокировок, но в том-то все и дело, что рецепт борьбы с натыканием на чужую блокировку записи широко известен - отлов TABLEUPDATE()=.F. плюс анализ ARROR на предмет наличия Error 109. Однако, как бороться с проблемой-близнецом - с блокированием индексного файла почему-то информации нету нигде. Неужели никто не нарывался? SYS(3052) как раз и дает нам такую возможность. С помощью нее мы можем запретить бесконечные попытки блокирования CDX (напомню еще раз, что это есть поведение по-умолчанию) и привязять время/количество попыток блокирования к установке SET REPROCESS. При такой стратегии отлов блокировки прост SET REPROCESS TO (скока там надо) + SYS(3052,1,.T.) + отлов TABLEUPDATE()=.F. и анализ AERROR на предмет Error 108 (File is in use by another user). Никаких зависаний и Record not available ... please wait....

ЗЫ В довольно известной и авторитетной книге Hacker's Guide to VFP высказано сомнение - мол, так ли необходима эта функция? Ситауция, мол, маловероятная, и всё в таком духе. Хм... ну не знаю-не знаю.... любой может проэкспериментировать. Откройте 2 фокса. Откройте в первом транзакцию и измените какое-нибудь поле любой записи, входящее в идексное выражение какого-либо тега SCX. А во втором фоксе попробуйте изменить любое (какое угодно) поле какой угодно записи, лишь бы оно тоже входило в какой-либо тег (не обязательно тот же самый). Результат - зависон и сообщение в статусбаре Record not available ... please wait.... . Только после завершения транзакции в первом фоксе, второй фокс выйдет из комы

> Он получит Record not available ... please wait. При этом получит это сообщение навечно

Почему навечно? Ошибки 108,109,1705 обязательно должны обрабатываться глобальным обработчиком ошибок с соответствующим сообщением пользователю и предложением повторить операцию или нет.

Мне кажется, что лучшим методом борьбы с блокированием тегов является отказ от использования индексов для полей с данными. В идеале индексы должны быть только для первичных и внешних ключей, и все. Естественно, если индексные выражения являют из себя нечто вроде "фамилия+имя+отчество+паспорт+адрес+...", то при определенной интенсивности транзакций неизбежно будет ошибка 109.

2 Aijik

Т.е. ты предлагаешь не блокировать индексные файлы вообще? Насчет того что блокируется весь CDX - так это помоему логично ведь индекс не таблица и в нем все записи должны зависеть от друг друга на то он и сделан. (Хотя может я ошибаюсь потому как так и не разобрался в его структуре :shuffle Так если на то пошло может и FPT не блокировать? Это и быстрее и ошибок с ним меньше...

2 XAndy

А что будет если не делать индексы в том же Kladr (600K записей) - а поиск вести по названию например улицы? Другой вопрос что этим злоупотреблять не стоит

Цитата:

"фамилия+имя+отчество+паспорт+адрес+..."

2 XAndy

Цитата:

Почему навечно? Ошибки 108,109,1705 обязательно должны обрабатываться глобальным обработчиком ошибок с соответствующим сообщением пользователю и предложением повторить операцию или нет.

А вы попробуйте перехватить через ON ERROR ошибку 108 в описанной ситуации. Первому, у кого получится - царевна и полцарства впридачу ;)
Насчет же того, что ON ERORR должен перехватывать 109... TABLEUPDATE + AERROR для этого есть, зачем сюда еще и ON ERROR привлекать-то?

С последним абзацем и вашем видением идеала не согласен совершенно. Вы уникальность чем контролируете хотя бы? Не UNIQUE-индексами? А оптимизация SEEK, ...FOR.... и SELECT...WHERE ? Вообще не нужна?



[i][small][color=Gray]Отредактировано (30.03.04 11:59)

2 JellFish

Цитата:

Т.е. ты предлагаешь не блокировать индексные файлы вообще?

Ну, если у тебя это получится, то тогда тебе вторая невеста и вторые полцарства, так уж и быть ;) Вмешаться во встроенные процессы блокировки CDX при транзакции невозможно. Движок-с... Да и зачем, собсно, ведь инструмент для разруливания "затыков" есть - SYS(3052)

Цитата:

того что блокируется весь CDX - так это помоему логично ведь индекс не таблица и в нем все записи должны зависеть от друг друга на то он и сделан

Логично конечно. Кто ж с этим спорит? В фоксе можно рулить и этим тоже, только почему-то об этом никто не говорит никогда. Я раньше нигде не встречал серьезного обсуждения проблемы блокирования CDX при транзакциях, по этой причине и возник этот тред



[i][small][color=Gray]Отредактировано (30.03.04 12:10)

при Sys(3052,1,.T.) кстати как раз 108 ошбика и ловится если Sys(3052,1,.F.) то именно и появляется "БЕГУШАЯ СТРОКА" ;) так что при использовании блокировок записей явно или нет лучше все-таки использоваить Sys(3052,1,.T.).
Ну мне так сильно кажется

2 piva
Тоже полцарства хочешь, да? ;) В правилах рыцарского турнира было же сказано "при описанных условиях" - это значит при установках по-умолчанию, т.е. при SYS(3052,1,.F.). Вот в этом-то случае как раз ON ERROR тихо и мирно будет послан подальше и error 108 пойман не будет. Более того, изменение, которое мы пытались внести до того, как нарвались на блокировку CDX, всё-таки тихим сапом будет внесено, но уже после того, как блокировка будет снята первым фоксом (aka будет завершена/откачена (откатана? ;) ) его транзакция)

при SYS(3052,1,.F.) отловить ошибку которой по определению не может быть из за
бесконечного ожидания ? (waits indefinitely) "Ну вы, блин, даете"
Жаль придется остатся без невесты и полцарства, а так мечталось ...

Цитата:

"Ну вы, блин, даете"

Для тех, кто не следил за нашим репортажем...

Цитата:

> Он получит Record not available ... please wait. При этом получит это сообщение навечно

Почему навечно? Ошибки 108,109,1705 обязательно должны обрабатываться глобальным обработчиком ошибок с соответствующим сообщением пользователю и предложением повторить операцию или нет.
....
А вы попробуйте перехватить через ON ERROR ошибку 108 в описанной ситуации. Первому, у кого получится - царевна и полцарства впридачу
.....
В правилах рыцарского турнира было же сказано "при описанных условиях" - это значит при установках по-умолчанию, т.е. при SYS(3052,1,.F.).

Владимир Максимов если мне не изменяет склероз на основе этого факта
(блокировки индексного файла на время до завершения транзакции) построил
свой триггер проверки уникальности полей в записях (который альтернативен
CANDIDATE индексу). Думаю он может чего-нить сказать по поводу...
А вообще хорошо что ты поднял эту тему - действительно малоизвестный факт
Ну насчёт его "малополезности" стоит поспорить и с авторитетами -
действительно поведение "по умолчанию" несколько повышает вероятность
натолкнуться на "тупик" при проведении транзакций...
Интересно в какой версии фокса добавили эту установку