О блокировке записей

[Viktor_Dnepropetrovsk]

Для Merlina. Конечно, интересно пообщаться с умным человеком, но все же хотелось бы узнать, это все опыт проб и ошибок на таком именно пути или умозаключения, следующие из того, что ...НИЗЗЯ. Неужели можно серьезно ставить вопрос о жестких структурах, если ты работаешь с 5-10 предприятиями и не ты диктуешь учетную политику, да если еще предприятия из разных отраслей? Что, 10 разных структур, 10 вариантов приложений, а завтра кто-нибудь еще захочет тебя объять в крепкие объятия. К сожалению в нашей UA - действительности только так и можно выжить (если ты конечно не внук Березовского, не зять Кучмы и не работаешь Генеральным Программистом Газпрома). Да насчет гипотетической и незначительной модификации это ты здорово загнул. Нам бы так жить. Но это лирика.
А по делу...

А смена даты при условии наличия ссылающихся документов допустима? Процедуркой-триггером проверим? Ну-ну.

А причем тут это? Какой даты? Да только ты меняешь дату действия записи справочника - сразу находи документы, которые этой смене противоречат, заблокируй это дело, и дай userу сообщение. Что тут военного? А при смене даты документа - наоборот, проверяй все ли аналитики соответствуют и не зацепищь ли ты ссылающиеся документы. Только напиши этот механизм максимально универсально - оно окупится. Геммор, конечно. но раз написав по-человечески, потом проблем сильно не собираешь. А то что-же: все сервер сделает на FK, Unique Index, процедурах и триггерах, а ты сделаешь простенькую формочку у клиента (конечно поработав с метаданными) и будешь пить пиво? Так не бывает. А насчет великих... Дак приехал бы к нам с запада кто-нибудь и написал бы к примеру ЗАРПЛАТУ. С нашим жизнерадостным правительством и правильным теоретическим подходом он бы годика через два повесился.

А серьезно, все дело в длинной транзакции, пока пользователь заполняет документ. И я не вижу нормальных способов сделать ее короткой при сложном документе. UpdateObject - хорошо, но где при этом все FK, триггера и т.п .? Геммор еще покруче. User, заполняющий документ из 500 позиций ( и конечно его не сохраняющий периодически, сколько ему не говори), видит результаты свой работы в конце. (Там нельзя, там товар закончился и т.п.). Вот в период этой длинной транзакции хотелось бы иметь "передаваемую" блокировку внесенной аналитики (т.е. блокировка для редактирования аналитики начинается с первого документа, выбравшего строку аналитики и заканчивается сохранением последнего живого документа, в котором она тоже выбрана , а для выбора - блокировка, если кто-то редактирует эту аналитику. И желательно не так, как у вас в статьях - может случится при дисконнекте мертвая блокировка, но добрый дядя сисадмин всем поможет). Если ты скажешь - что это вредно для здоровья, то уж и не знаю... Все это сделано на холостом упдате, на with lock для таблицы блокировок аналитик, доп.транзакции и ID сurrent_transaction. Какие дырки на взаимном холостом упдате? И кстати, при внесения аналитики в документ применяется короткая транзакция записи в таблицу блокировок, начинающаяся с холостого упдате. Вся фишка в снятии мертвых блокировок, а для этого применяется with lock в транзакции документа по current transaction в таблице блокировок и для предупреждения дырок - внесение в таблицу блокировок заголовочной записи по транзакции с пустой аналитикой (в момент выбора первой аналитики) Уборка в таблице блокировок – кооперативная, при вызове справочника и входе в режим редактирования. В двух словах трудновато….
А насчет не там смотрел по программам: ну-ну, назови если видел, если это конечно не сов.серетно.
А по поводу for update. В документации F 1.5 эта конструкция в with lock указана опционально. т.е. может быть, а может не быть. Как понимать - дело только в формировании пакетов и на поведение блокировки никак не влияет? Извини, но я об твою статью глаза сломал, но что-то этого не увидел.

[kdv]

аналитика - это вообще то несколько иное, чем атрибуты записей.

все сервер сделает на FK, Unique Index,

unique - это альтернативный ключ, который например в FB 1.5 допускает null. Первичный ключ это primary key, а не unique.

неужели можно серьезно ставить вопрос о жестких структурах, если ты работаешь с 5-10 предприятиями и не ты диктуешь учетную политику, да если еще предприятия из разных отраслей?

универсальный решатель задач? автоматизация хаоса?

Извини, но я об твою статью глаза сломал

у меня стойкое ощущение что или ты ее не понял, или не хочешь понимать.

В документации F 1.5 эта конструкция в with lock указана опционально

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

для примера рекомендую вообще забыть про всякие идентификаторы транзакций, и подумать, как бы твоя задача решалась на серверах с другой архитектурой - например на "блокировочниках".

[Merlin]

Для Merlina. Конечно, интересно пообщаться с умным человеком, но все же хотелось бы узнать, это все опыт проб и ошибок на таком именно пути или умозаключения, следующие из того, что ...НИЗЗЯ.

Конечно же умозаключения жителя Башни из Слоновой Кости. Правда работающего успешно 25 лет только в области АСУП, кою нынче модно именовать ERP, и на реляционных СУБД и на не реляционных.

Неужели можно серьезно ставить вопрос о жестких структурах, если ты работаешь с 5-10 предприятиями и не ты диктуешь учетную политику, да если еще предприятия из разных отраслей?

Плач по горестной судьбине и мысли вокруг велосипеда поскипаны, потому что действительно в двух словах не того, а на большее количество слов, сам понимаешь, сил-времени ни у тебя ни у меня нет. Осуждение заходит в тупик Предлагаю завязать.

насчет не там смотрел по программам: ну-ну, назови если видел, если это конечно не сов.серетно.

Обобщённый решатель задач? Могу порекомендовать готовый - SAP/R3. Около 15 000 таблиц, когда я в последний раз в него заглядывал года 3 назад. Есть и попроще, Axapta, например. У меня ещё проще, как я уже говорил. И у многих друзей моих, но мы не замахиваемся на глобализм. Эти толпы таблиц растут не только из объёма задач, но и из подхода - часть решается структурными способами, часть алгримтимическими, исходя в том числе и из особенностей инструмента. Например, по-хорошему бухгалтерия - это не система, а подсистема, базирующаяся на подсистеме документооборота. И 500-строчные документы регистрируются во второй без ограничений и учётных заморочек, а проводки и связанная с ними функциональность идёт вторым планом в своём темпе и со своими проблемами. А сложная аналитика - ещё подсистема, и ещё, и ещё... Такая декомпозиция функциональности, связанная с дублированием в некотором смысле информации, значительно увеличивает объём нашей работы, но в конце концов сильно упрощает жись...

А по поводу for update. В документации F 1.5 эта конструкция в with lock указана опционально. т.е. может быть, а может не быть. Как понимать - дело только в формировании пакетов и на поведение блокировки никак не влияет? Извини, но я об твою статью глаза сломал, но что-то этого не увидел.

Хмм, заглянул - твоя правда. Здесь лежит первый вариант статьи, а котором на это указано, но до конца не дожёвано. Это не мой промах, посылал в своё время дополнения и сюда и на interbase-world. Русского последнего варианта у меня под рукой сейчас нет, но могу дать ссылки на португальский и английский Ладно, если с английским терпимо, разберёшься, кидаю нужный абзац:

Usage of With Lock option in ordinary Select statement requires the same precautions as Select For Update but complicated with the next consideration: you can’t easily predict how many rows will be locked at once when you open query if you select not a single row. Even if query isn't connected to DBGrid-kind control which forces a fetch of the amount of rows to be placed on the screen and you have the intention to process rows step by step, server will fetch the amount of rows enough to fill network packet or even two – one to be sent on client immediately, another to be ready for next client’s fetch request. This amount is dependent on the size of the packet used in your network, size of the row in the table and network protocol compression algorithm. So when using ordinary Select With Lock on cursors you lock not one row or the whole cursor but an unknown amount of rows on query opening. We intentionally recommend to use locking only with singleton selects to avoid unpredictable behaviour of the application. If you still need cursor locking do fetchall immediately after open if you want to lock all rows or use Select For Update if you want step by step processing. Don't use this With Lock option to lock whole tables. To do this take a look on consistency isolation level in documentation.

[Viktor_Dnepropetrovsk]

Для kdv. Мы конечно не асы еще, но не надо вот так уж - PK c Unique index мы и во сне не спутаем.
Да ребята... Один признает, что не все нам (RU, UA и далее без остановок по СНГ) расказал, а в первую очередь помог братьям по разуму по португальской и английской матери (спасибо за честность), а второй по прежнему советует ломать глаза об статью и тыкает в низкий IQ. Вы на свой сайт то заходите? Извините за моветон, но слов из песни не выбросишь. Насколько я понял из перевода (excuse me му litle Inglish, спасибо учителям советской школы и университета) в части блокировки в обеих вариантах все то же самое, т.е. нет безусловной гарантии блокировки курсора (where) и можно въехать в ситуацию, при которой delete from <A> where ID_TR=<B> может вызвать удаление записей с ID_T = B даже если попадется одна незаблокированная запись, ее выберут первой и сразу грохнут, а потом на второй получим исключение. Или это не так? Лучше бы не вводили такую блокировку, или оограничили типа singleton selects.

[Merlin]

Да ребята... Один признает, что не все нам (RU, UA и далее без остановок по СНГ) расказал, а в первую очередь помог братьям по разуму по португальской и английской матери (спасибо за честность), а второй по прежнему советует ломать глаза об статью и тыкает в низкий IQ. Вы на свой сайт то заходите? Извините за моветон, но слов из песни не выбросишь. Насколько я понял из перевода (excuse me му litle Inglish, спасибо учителям советской школы и университета) в части блокировки в обеих вариантах все то же самое, т.е. нет безусловной гарантии блокировки курсора (where) и можно въехать в ситуацию, при которой delete from <A> where ID_TR=<B> может вызвать удаление записей с ID_T = B даже если попадется одна незаблокированная запись, ее выберут первой и сразу грохнут, а потом на второй получим исключение. Или это не так? Лучше бы не вводили такую блокировку, или оограничили типа singleton selects.

Во-первых. Насчёт того, что Select For Update уже 13 лет существует и предназначен именно для того, чтоб таскать по одной записи, в то время как просто Select таскает неопределённой величины пакетом, в том варианте статьи, который присутствует на www.ibase.ru, написано. Для того, чтобы сделать отсюда вывод о том, что при добавлении опции With Lock то же самое будет касаться и блокировки, братьям по разуму, независимо от их языковой и половой принадлежности, а также сексуальной ориентации и цвета кожи, видимо, надо иметь во лбу не менее девяти с поповиною пядей. Тем не менее, для тех, кто на бронепоезде, я таки дописал впоследствии этот абзац.
Во-вторых. Родным моим языком является русский, и как это ни странно, думать и излагать свои мысли я имею обыкновение таки на нём. Первый вариант был размещён здесь. Английский вариант появился по просьбе и главным образом трудами Марины Новиковой (www.intetbase-world.com) и англоязычной тётеньки Helen Borrie. Португальский появился по инициативе и силами Eugenio Reis в качестве вторичного перевода с английского. Как опять же написано в статье, готовилась она во время актуальности RC3. Опция With Lock в обычном Select появилась только в Final Release. Этот абзац (и по-моему ещё кое-что по мелочи) в качестве дополнения был мною после этого отослан в русском варианте сюда и Марине, в английском Марине, Helen и Eugenio. Почему на сайтах IBPhoenix и CFLP эти дополнения появились, а на наших нет, мне неведомо. Нарциссизмом в степени, провоцирующей на то, чтобы бродить по инету и перечитывать ежедневно собственные статьи, я не страдаю.
В-третьих. Лично я был против введения этой фичи когда она ещё задумывалась именно потому, что был уверен, что толпы идиотов после этого перестанут думать об уровнях изоляции и структурах хранения данных в принципе и начнут складывать всё в одну таблицу и блокировать всё направо и налево. В чём пытался убедить её автора Колю Самофатова в приличных выражениях на публике и в не очень в привате. Не преуспел. Именно поэтому и написал статью, движимый человеколюбием, пытаясь объяснить чайникам где её пользовать можно и нужно и как, а где нет и почему.
В-четвёртых. Как уважаемый мыслит себе проверку singleton-овости селекта на _синтаксическом_ уровне? Или он предпочитает не утруждать себя обмысливанием предложений всесторонне перед озвучиванием, а изливать в пространство поток неотфильтрованного сознания? Нехай слушающие напрягаются как мои гениальные идеи реализовать или обдумывают их и отговаривают меня, чтоб я согласился, ну так уж и быть, пусть будет как у вас, бестолковых, получилось?
В-пятых. Интересный таки народ изобретатели велосипедов. Всё-то им неправильно и сервера делают и статьи пишут и на форумах отвечают. Именно из-за этого я, например, с писанием оных и завязал. И никогда не выкладывал в свободный доступ имеющийся набор проектных решений. И технологических штампов прикладного и инструментального кода. Реакцией 99% потребителей будет объявление автора самовлюблённым жлобом, недостаточно о них заботящимся и требования дальнейшей неустанной проработки ИХ проектов и ИХ кода. Или приспособления и переделки выложенного к их велосипедам. Каждому в отдельности. Как говорится, извиините, бисер кончился.

[Viktor_Dnepropetrovsk]

Sorry, не сразу написал ответ (внезапный отпуск). Грубовато конечно размазали. Вижу, сильно разозлил патриархов. Но в общем-то вины особой не чувствую. Про for update ни в книге « Мир Interbase», ни у Склярова (то, что единственно доступно русскоязычному читателю, масса литературы) ничего толком нет, в LahgRef.pdf по Interbase 6.0 что-то невнятно сказано, а делать логические выводы про блокировку в этом режиме из того что сам надумал при разработке коммерческого заказа довольно опасно. Но это так, не главное (самое интересное, что вразумительный ответ я получил, только сильно разозлив, а то что меня приписали к толпе идиотов… ничего, не тургеневские барышни, переживем). Да, опыта в SQL маловато, поэтому и задаю может быть дурацкие вопросы, но нужно иметь четкие ответы, из которых и складываются аксиомы. Кстати, насчет синтаксиса блокировки единичной записи я согласен – нельзя, но я в контексте всей этой ругани переделал блокировку для добавления к блокируемому курсору записей по одной за счет «select … where ID =:parID and … with lock » (меня это вполне устраивает по схеме блокировки) .
Но. к сожалению, самое неприятное из того, что я вынес из этой переписки – это реклама для толпы идиотов (и изобретателей велосипедов и мясорубок ) жесткого подхода к структуре. Т.е. есть Cчет расчета с поставщиками – давай отдельную таблицу с полем ID клиента, завтра добавляй ID договора (вздумалось получать сальдо по поставщику в рамках договора) … Для подотчетников – отдельная таблица – там уже ID сотрудника, ну и так далее. Учитывая. что в некоторых из наших организаций существует план счетов емкостью > 2500 ед (прихоть великих киевских экономистов) объяснять далее не буду, кому нужно, поймет. Поэтому и другой подход к структуре . Насчет записи справочника – «живая-дохлая» - это … А отчеты за прошлый период никому не нужны…?
Кстати, на благословенном clipper выкручивались сменой структуры по ходу (программным путем) с перекачкой данных, благодаря чему и могли ставить комплекс на разнородных предприятиях , да еще и спокойно переживать смену политики учета (кстати, вообще великолепная фишка cliiper – это макроподстановки , т.е. при одном и том же коде – сохранять в таблицах разные алгоритмы расчетов на своем макроязыке). Cliiper почил в бозе, не сильно надежен в сети Windows (чего в DOS+Nowell не наблюдалось), переходим на Firebird. И что? Имея такой мощный механизм join, хранимых процедур, UDF, транзакций при современном быстродействии ПК просто глупо втискивать себя в рамки жестких структур по определению. Если бы я пробовал объектный подход 10 лет назад на 486DX100, конечно я сказал бы - нет. (Да и разница в быстродействии Fb1.0 – Fb1.5 –огромная). И подчеркиваю – там где можно FK – применять обязательно.
И меня вы тоже разозлили, поэтому, если захочется, я наковыряю схему блокировки в псевдокоде.

[kdv]

Про for update ни в книге « Мир Interbase», ни у Склярова (то, что единственно доступно русскоязычному читателю, масса литературы)

ну, Скляр это вообще просто перевод Programmers Guide от IB 5, а во время написания "Мир Interbase" про for update было нечего писать. Ну по одной записи выдает результат, и что? Спросил бы у меня, я б тебе это сказал лет 8 назад.

переходим на Firebird. И что? Имея такой мощный механизм join, хранимых процедур, UDF, транзакций при современном быстродействии ПК просто глупо втискивать себя в рамки жестких структур по определению.

ну, знаешь, как бы, есть "нежесткие" системы. я сам такую делал еще на Paradox в 93 году. На IB делал в 96-ом. И общался с людьми, которые тоже делали подобные системы...

И меня вы тоже разозлили, поэтому, если захочется, я наковыряю схему блокировки в псевдокоде.

дело хозяйское, было бы из-за чего злиться. меня смущает другое - если тебе так ненавистен версионник с отсутствием блокировок, то никто не запрещает попробовать решить ту же самую задачу на MS SQL, к примеру. Вдруг получится?