gifts2017

Для чего нужны блокировки

Опубликовал Олег Филиппов (comol) в раздел Программирование - Практика программирования

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

Если прочитать методику перевода конфигурации на управляемые блокировки от 1С - можно там найти много всего интересного и пугающего. На самом деле всё просто: В свойствах конфигурации меняете режим блокировки данных - "Управляемый". Всё. Могу вас поздравить - вы только что перешли на управляемые блокировки.  На самом деле всё несколько сложнее - но не на много.

Для начала небольшой теоретический экскурс - зачем нужны блокировки: У кого есть доступ конечно можно прочитать здесь: http://kb.1c.ru/articleView.jsp?id=30 1С озаботились написать достаточно доступную статью про блокировки данных.  У кого же доступа нет в двух словах опишу для чего нужны блокировки:

Пример 1. Если после включения управляемых блокировок ничего не делать, и при этом начать параллельно проводить 2 документа (один из них ведь всё равно на долю секунды раньше), то получим приблизительно следующую картину:

Транзакция 1 Транзакция 2 Состояние остатков
Начало | 1 шт
| Начало 1 шт
| | 1 шт
Чтение остатков | 1 шт
| Чтение остатков 1 шт
| | 1 шт
Списание с остатков | 0 шт
| Списание остатков -1 шт
Завершение |  
  Завершение  

Что здесь не так? Контроль остатков дал сбой. 2-ой документ успел прочитать остатки раньше, чем 1-й успел их записать. При этом увидел, что на остатках 1 штука и спокойно списал их вслед за первым. Стоит оговориться, что по факту блокировки здесь всё-таки будут. 2 документа не смогут списать остатки одновременно, это необходимо для логической целостности БД, но для решения прикладной задачи в данном примере вряд ли полезно. 

Теперь постараемся исправить ситуацию - в коде проведения документа пропишем установку эксклюзивной управляемой блокировки непосредственно перед чтением остатков:

Транзакция 1 Транзакция 2 Состояние остатков
Начало | 1 шт
| Начало 1 шт
Блокировка | 1 шт
Чтение остатков | 1 шт
| Попытка блокировки 1 шт
| Ожидание на блокировке 1 шт
Списание с остатков Ожидание на блокировке 0 шт
| Ожидание на блокировке 0 шт
Завершение Ожидание на блокировке 0 шт
  Блокировка 0 шт
  Чтение остатков 0 шт
  | 0 шт
  Отказ 0 шт

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

Ну теперь, когда разобрались зачем блокировки нужны остаётся только установить управляемые блокировки там где это нужно: а именно -только там где производится контроль остатков. Если у вас в базе менеджер имеет право провести документ вне зависимости от того есть товар(деньги) на остатках или нет, зачем вам тогда блокировки? Можете их просто не устанавливать, или прописать и закомментировать до лучших времён. Если же у вас производится контроль остатков то как правило это 3-4 регистра, ну максимум 10-ок.  Контроль можно подвесить как в общие процедуры и функции, так и в модули набора записей РН. Код предельно простой, открываем синтаксис помошник - смотрим:

Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.ТоварыНаСкладах");
ЭлементБлокировки.УстановитьЗначение("Качество", Справочники.Качество.НайтиПоКоду("1"));
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
ЭлементБлокировки.ИсточникДанных = ДокументОбъект.ВозвратнаяТара;
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Номенклатура", "Номенклатура");
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Склад", "Склад");
Блокировка.Заблокировать();

Собственно всё сразу понятно - блокируем "товары на складх", 1 измерение становим в явном виде, значения 2-х других возьмём из источника данных - ТЧ документа.

Те кто читал книжки по 8.2 наверное помнят о "Новой логике проведения" - когда контроль остатков производится после записи движений документа. Задвались вопросом зачем это? А вот эту же табличку перерисуем так что контоль остатков и блокировка будут после записи движений:

Транзакция 1 Транзакция 2 Состояние остатков
Начало | 1 шт
| Начало 1 шт
| | 1 шт
Списание с остатков | 0 шт
| Списание с остатков -1 шт
Блокировка | -1 шт
Чтение остатков Попытка блокировки -1 шт
| Ожидание на блокировке -1 шт
| Ожидание на блокировке -1 шт
Завершение Ожидание на блокировке -1 шт
  Блокировка -1 шт
  Чтение остатков -1 шт
  | -1 шт
  Отказ 0 шт

Разница с виду не значительная - прирост производительности получаем за счет того что на время списания остатков (запись их в базу, что, собственно занимает время) блокировки ещё нет. Блокировка возникает позже к концу транзакции, куда вынесен контроль отрицательных остатков, бизнес логике приложения это вполне удовлетворяет.

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

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

Для варьирования между такими разными задачами в СУБД придумали уровни изоляции. Устанавливая уровень изоляции транзакций можно сказать СУБД какие блокировки накладывать в разных случаях (при записи и при чтении в транзакции) в разных случаях накладываются S (можно читать нельзя писать) или X (нельзя ни читать ни писать) блокировки.

Так в автоматическом режиме у вас почти всегда будет уровень изоляции SERIALIZABLE, который будет накладывать X блокировки где нужно и где не нужно, что будет существенно портить вам жизнь

А в управляемом у вас будет READ COMMITED, который будет накладывать и тут же снимать S блокировку при чтении, и X только при записи. Самый хитрый уровень. Быстро накладываемая S блокировка как раз позволяет проверить не наложена  ли где на эти данные X блокировка, что и обеспечивает чтение только согласованных данных, как принято для данного уровня изоляции, а в случае если вы прочитали и выполнили действя, рекоммендованные в предыдущей статье, то не будет даже S блокировки при чтении, таким образом на уровне СУБД будет блокироваться только запись во время записи - что правильно и необходимо для сограсованности данных.

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

См. также

Подписаться Добавить вознаграждение

Комментарии

0. Олег Филиппов (comol) 27.09.11 05:17
Многие программисты "борются" с блокировками, но в попытках их "победить" не всегда задумываются "зачем они вообще нужны?" "а может от них совсем отказаться?" удивительно, но факт - от блокировок можно просто отказаться.

Перейти к публикации

1. Доржи Балбаров (Angeros) 27.09.11 05:17
Плюсанулбы источник. Автору за копипаст 0
2. Олег Филиппов (comol) 27.09.11 12:40
Вообще источник я :), если есть комментарии и вопросы - спрашивайте. Честно стыренная только картинка, потому как без неё не пропускали статью. Да и очевидно что "в официальных источниках" таки статьи не пропустят... к сожалению немного мы тут расходимся с позицией 1С. Статья родилась после беседы с генеральным директорам не мелкой компании, который говорил "как трудно им бороться с блокировками" из за большого количества ЗАКАЗОВ :). Товар скоропортящийся и его приходится ВЫКИДЫВАТЬ :).
3. Алексей Роза (DoctorRoza) 27.09.11 19:46
вот за это -
У кого есть доступ конечно можно прочитать здесь: http://kb.1c.ru/articleView.jsp?id=30 1С озаботились написать достаточно доступную статью про блокировки данных. У кого же доступа нет в двух словах опишу для чего нужны блокировки:
минус оставил бы без зазрения совести ..
4. Олег Филиппов (comol) 27.09.11 23:35
(3) DoctorRoza, так и не поняли что до вас хотел донести... вот где-то так бывает появляются люди, которые ничего не хотят читать, а потом "воюют" с блокировками :)
5. Сергей Рудаков (fishca) 27.09.11 23:53
http://kb.1c.ru/articleView.jsp?id=30 - Данная статья является фрагментом книги П.С.Белоусов, А.В.Островерх "1С:Предприятие: от 8.0 к 8.1".
Дата выхода книги: ноябрь 2007.

Так что кому надо ознакомиться поближе с блокировками ищите книжку.
(1) это не копипаст.
6. afk afk (afk) 28.09.11 10:42
(4) в Таблице №3, Транзакция 1 почему успешно завершается? На момент чтения "состояние остатков" = -1.
FeSTy; softgarant; bendarik; HiGHT; ngold; echo77; +6 Ответить 1
7. Олег Филиппов (comol) 28.09.11 11:49
Смысл колонки "Состояние остатков" в том чтобы показать физические остаки в СУБД без учета фиксации транзакций. Как раз чтобы показать как могут получиться "-1" в случае отсутствия блокировки при параллельном проведении, и почему 2-я транзакция откатывается.

В таблице 3 1-я транзакция считала остатки ещё до фиксации изменений 2-ой транзакцией. Соответственно минуса там ещё не было... но по сути списали они уже в "-". И если бы не было блокировки обе транзакции зафиксировались бы и получился бы "-".
8. Владимир (hogik) 28.09.11 21:40
(0)(6)(7)
Олег.
На мой взгляд, в таблице #3 представлен странный алгоритм. Цель контроля - проверить отрицательные остатки? А если начальное состояние остатков, до начала обеих транзакций, достаточно для списания, то вторая транзакция зафиксируется? И что получится на остатках?
Мне представляется ошибочным посыл, что блокировки требуются "только там где производится контроль остатков"(с) в контексте "контроль отрицательных остатков"(с).
Режим "отключен контроль отрицательных остатков"(с) не означает, что остатки могут списываться произвольным образом. Для этого существует другой режим - "вообще не вести остатки". ;-) Например, у нас включен режим "разрешить отрицательные остатки" для розничного зала. Т.е. существует такой принцип - если продавец держит в руках товар, то он имеет право его продать (пробить чек), даже если в компьютерной базе остатки на нуле. Но эти "минуса", потом, тщательно анализируются складскими работниками и службой безопасности... ;-)
На мой взгляд любое изменение данных в БД состоит из трех этапов:
1) Чтение исходных данных в оперативную память.
2) Изменение исходных данных в оперативной памяти.
3) Запись нового значения в базу данных.
И если до выполнения этой последовательности не выполнить блокировку, то результат обновления базы данных будет искажен в многопользовательском режиме.
Или я ошибаюсь? ;-)
9. Александр Крынецкий (echo77) 28.09.11 21:54
(7) Третью таблицу по подробней разрисуйте, пожалуйста, в том месте, где остатки становятся -1
10. Олег Филиппов (comol) 28.09.11 22:50
(8) hogik,
Или я ошибаюсь? ;-)
К сожалению именно так - вы ошибаетес, это оочень популярное заблуждение. Иначе я бы не заморачивался и не писал эту статью, чтобы по 10 раз одно и то же не объяснять.

Давайте по порядку, а то чувствую это ещё пару раз спросят :)

Режим "отключен контроль отрицательных остатков"(с) не означает, что остатки могут списываться произвольным образом
К сожалению именно это он и означает - остатки просто спсываются произвольным образом (речь не идёт о партиях)

Но эти "минуса", потом, тщательно анализируются складскими работниками и службой безопасности... ;-)
Вот как раз для вас статья. В рознице, конечно вам блокировки не нужны если у вас файловая версия в этом случае, а если все работают в одной базе то как раз для вас

И самое интересное:

На мой взгляд любое изменение данных в БД состоит из трех этапов:
1) Чтение исходных данных в оперативную память.
2) Изменение исходных данных в оперативной памяти.
3) Запись нового значения в базу данных.
И если до выполнения этой последовательности не выполнить блокировку, то результат обновления базы данных будет искажен в многопользовательском режиме.


Дело в том что так и происходит, более того блокировки на уровне СУБД будут, СУБД не даст вам нарушить ссылочную целостность, т.к. используется уровень изоляции READ COMMITED. Т.е. противроречивую информацию записать не получится. Но такие блокировки логичны с точки зрения "житейской логики", что позволило мне назвать статью "убираем блокировки" 90% из них это всё-таки чтение для контроля остатков
11. Олег Филиппов (comol) 28.09.11 23:19
(9) echo77, Я уж не знаю как подробнее - попробую так:

Имеем клиент-серверную систему и 2 запущенных клиента, оба подключены отладчиком к одному конфигуратору, в обоих открыт документ реализации всё заполнено, введено. В системе включена "новая логика проведения" и управляемые блокировки - когда остатки контролируются после проведения документа (т.е. сначала мы их пишем, потом уже проверяем на наличие отрицательных). Ставим точку останова перед процедурой наложения управляемой блокировки. Вот когда оба сеанса будут висеть на точке останова перед процедурой блокировки - снимаем остаки - там будет "-1". А потом отпускаем точку останова и смотрим как одна из транзакций "откатится", потому как будет ждать блокировку, а потом откатится, потому как получит "-1" в остатках.
12. Владимир (hogik) 28.09.11 23:35
(10)
Олег.
Чувствую у нас получится перпендикулярный разговор. ;-)
Я "не понимаю" ЭТОГО:
1) "остатки просто спсываются произвольным образом (речь не идёт о партиях)"(с)
Т.е. несколько задач могут прочесть значение остатков в память, изменить их и записать в БД случайным образом? Например, три задачи в начале собственной транзакции считывают из БД значение остатка - 3 шт. Каждая вычитает из остатка по 1 шт. Получает значение 2 шт. И по мере возможности записывает в базу значение 2 шт. А мне казалось, что после выполнения этих трех транзакций на остатках должно образоваться нулевое значение. И какое это отношение имеет к партиям? Чем партии отличаются от "просто общих" остатков на складе по конкретной позиции товара?
2) "В рознице, конечно вам блокировки не нужны если у вас файловая версия в этом случае, а если все работают в одной базе то как раз для вас"(с)
Я не понял ЧТО "как раз для" меня? У меня нет никакой файловой версии. У меня нет даже никакой 1С-ины... :-) Всё, что написано в Вашей публикации применимо к любой ИС на любой СУБД. Точнее - не применимо.
3) "СУБД не даст вам нарушить ссылочную целостность, т.к. используется уровень изоляции READ COMMITED."(с)
Поясните, пожалуйста, какое отношение имеет "ссылочная целостность" к моему примеру из пункта #1.
13. Олег Филиппов (comol) 28.09.11 23:46
(12) hogik, Я просто думал я с чуть более опытным человеком, общаюсь, сорри.
1) Конечно пишутся не остатки а движения. Мы в итоге знаем сколько мы хотим записать, остатки на движения никак не влияют - это общая логика 1С, вам просто нужно прочитать где-то что есть таблица итогов, есть движения, пересчет итогов и т.п. - тогда поймёте.

2) Вот не всегда... дело в том что учет остатков в 1С - это 2 таблицы остатки и движения. пишем только движения, остатки регламентно пересчитываются. Остатки к примеру, в Dynamics Ax - это индекс на таблице движений там уже могут проблемы начаться при таком отношении...

3) Нуу мне просто в голову не приходила мысль что остатки можно считать а потом записать... в принципе в теории наверное можно, какую-нить свою систему придумать на этом принципе... поэтому я и сделал вывод что вы в целом боитесь только за разрушение данных и вас успокоил :)
14. Владимир (hogik) 29.09.11 00:24
(13)
Олег.
1) "Я просто думал я с чуть более опытным человеком, общаюсь"(с)
Опыт бывает разный и на разных системах полученный... ;-)
2) "пишем только движения, остатки регламентно пересчитываются"(с)
Вот это и есть "опыт 1С". В "нормальных" системах разработчики понимают, что "остатки регламентно" не пересчитываются, а существуют для оперативного использования - в любой момент мгновенное получение. К примеру, почти как в "Dynamics Ax"(с).
3) "Нуу мне просто в голову не приходила мысль что остатки можно считать а потом записать"(с)
А в этом алгоритме http://v8.1c.ru/overview/Term_000000642.htm делается иначе?
15. Олег Филиппов (comol) 29.09.11 01:33
3) "Нуу мне просто в голову не приходила мысль что остатки можно считать а потом записать"(с)
А в этом алгоритме http://v8.1c.ru/overview/Term_000000642.htm делается иначе?


Не поверите - иначе :)))

В "нормальных" системах разработчики понимают, что "остатки регламентно" не пересчитываются

ммм... они как бы в любой момент доступны естетсвенно. Просто есть таблица остатков - к ней досчитываются обороты. Потом регламентно пересчитываются остатки и дописываются обороты - вполне адекватное решение. Кстати именно в этом моменте я очень подозрительно смотрю именно на Dynamicx Ax. Не было ещё опыта его эксплуатации с большим количеством пользователей, но чувствую там могут быть проблемы... и ещё какие...
16. Владимир (hogik) 29.09.11 02:41
(15)
Олег.
Последний к Вам вопрос. ;-)
Т.е. в методе ДобавитьРасход() не выполняется обновление остатков по "принципу" трех действий из (8) сообщения?
P.S. Остатки не могут быть "в любой момент доступны"(с), если "регламентно пересчитываются"(с), т.к. доступность остатков подразумевает их актуальность сразу после воздействия на них "документом" (в терминах 1С). Это не остатки, а жесть... ;-) Раньше это называлось пакетным расчетом (обработкой). Лет, так, 40 назад... :-)
P.P.S. Кстати об "Dynamicx Ax"(с). Рекомендую посмотреть как "ведутся" остатки в других системах. В некоторых, даже, на уровне обновления (интерактивного ввода) отдельной строки "документа". И такой режим, в частности, решает проблему ожидания блокировок. Т.к. в транзакциях выполняется только необходимые действия для отдельной "хозяйственной операции"(ХО), а не для искусственного объединения ХО в документы наделяемые удивительным понятием "провести документ". ;-)
17. Григорий Самонов (pirat123457) 29.09.11 08:45
Автору + действительно полезная тема, сам сталкивался с таким на производственном предприятии, работаю круглые сутки, блокировки возникали очень часто бухгалтерия и диспетчера ругали 1С 8 кто как мог :) Но ничего все решилось и счастье все довольны, пришлось потрудиться конечно, но результат говорит сам за себя за последние 2 года об блокировках уже давно забыли на предприятии....
18. Олег Филиппов (comol) 29.09.11 10:26
(16) hogik,
методе ДобавитьРасход() не выполняется обновление остатков по "принципу" трех действий из (8) сообщения
- нет - не добавляются.

Остатки не могут быть "в любой момент доступны"(с), если "регламентно пересчитываются"
я просто объясняю "птичьим языком" но по этой теме много что написано... вдаваться в подробности не охота... смысл в том что в 1с остатки это всегда запрос по 2-м таблицам.

Рекомендую посмотреть как "ведутся" остатки в других системах.
эх... я бы с удовольствием... было бы время и доступ... но тут убить надо неделю, а интерес по сути чисто академический. Я пока видел как остатки ведутся в русских "Парус", "фолио".. по сравнению с ними 1с просто супер технологична. Видел подход в Dynamics... он просто другой.. пока ничего не могу сказать про него.
19. afk afk (afk) 29.09.11 10:29
20. Владимир (hogik) 29.09.11 16:21
(18)
Олег.
Еще раз повторю.
Изначальный посыл Вашей статьи - ошибочен. И, естественно, дальнейшее обоснование - бессмысленны.
Блокировки нужны не "только там где производится контроль остатков"(с)
Они требуются в процессе, собственно, обновления остатков.
Т.к. во всех системах, для подобных задач, используется "принцип" трех действий из (8) сообщения. И эти блокировки следует "накладывать" даже если установлен режим "разрешить отрицательные остатки". Т.к. и отрицательные остатки должны быть верными, хотя и отрицательными. Выше по теме, я пояснил ВСЕ эти моменты.
Ставлю "минус" на публикацию, как предостережение пользователям от использования подобных методик... :-(
21. Ийон Тихий (cool.vlad4) 29.09.11 16:31
я бы тоже наверное минус поставил. На этот раз википедии доверяю больше
Блокировка (англ. lock) в СУБД — это отметка о захвате объекта транзакцией в ограниченный или исключительный доступ с целью предотвращения коллизий и поддержания целостности данных.
22. Ийон Тихий (cool.vlad4) 29.09.11 16:33
Именно контроль целостности данных, а не остатков. Остатков может вообще не быть.
23. Олег Филиппов (comol) 29.09.11 16:34
(21) cool.vlad4, Это слишком общее определение. "1С - это платформа для разработки бизнес-приложений" :))))
24. Ийон Тихий (cool.vlad4) 29.09.11 16:35
Если отклонится от 1С, - есть системы использующие другой принцип,( например CouchDB) - http://ru.wikipedia.org/wiki/MVCC , затем там мержится версии, но в бизнес приложениях это неактуально.
25. Ийон Тихий (cool.vlad4) 29.09.11 16:36
(23) Ну например - конкретный случай, я беру пишу счет, этот же счет открывает другой чел и меняет - блокировок нет, - и где гарантия целостности данных, когда на выходе я получаю совершенно не то, что писал.
26. Ийон Тихий (cool.vlad4) 29.09.11 16:49
Прочитал вашу вторую статью http://infostart.ru/public/91879/ , вот за нее плюс(в смысле понравилась), но единственно, что - неплохо бы выражатся яснее. Собственно подозреваю и здесь спор только из-за этого.
29. Ирина Пятакова (Alraune) 29.09.11 17:08
30. Александр Иванов (dkprim) 29.09.11 17:38
нормальная статья. автору спасибо :)
31. Олег Филиппов (comol) 29.09.11 17:46
(20) hogik, Хорошо, согласен напишите свою конфигурацию, в которой вы будете

1) "Читать все остатки"
2) "МЕНЯЙТЕ ОСТАТКИ В ПАМЯТИ"
2) "ЗАПИСЫВАТЬ ОСТАТКИ"

И выложите на инфостат, а мы дружно на это всё посмотрим.... и откомментим конечно :))))). Сам лично "+" поставлю - чтобы подольше повисело и народ посмотрел.
32. Олег Филиппов (comol) 29.09.11 17:48
(26) cool.vlad4, Я на самом деле ожидал что ко второй статье будет больше внимания... там действительно "Ноу Хау" а здесь просто изложение простых и понятных вещей... над которыми просто не все задумывались...
33. Олег Филиппов (comol) 29.09.11 17:51
(25) cool.vlad4, Блокировки то будут... при записи их никто не отменял... я пишу просто про то что блокировки В ЯВНОМ ВИДЕ в коде можно убрать... а SQL будет блокировать исходя из уровня Read Commited - в ващем примере он вполне поможет.
34. Ийон Тихий (cool.vlad4) 29.09.11 17:56
(32) я ту статью увидел второй и собственно их порядок не регламентирован (стоило бы указать тогда часть1, часть2 и ссылка), насчет ноухау, - о данной sql фиче я знал, но по поводу использования в 1С, да пожалуй ноухау.
(33) я и понял потом(после прочтения той статьи) о чем речь, почему и посоветовал выражатся яснее
35. Олег Филиппов (comol) 29.09.11 18:10
(34) cool.vlad4, Об этой фиче в 1С тоже знают, с Рупасовым я даже обсуждал... вот только не скоро оно ещё в платформе появится, тем не менее... :)
36. Владимир (hogik) 29.09.11 18:15
(31)
Олег.
Я не вижу никакой связи между моими сообщениями в данной теме и Вашим (31) сообщением. Алгоритмы изменения "остатков" ВСЕГДА и ВЕЗДЕ делаются так, как я написал в (8) сообщении. А для уменьшения времени блокировок не следует "Читать все остатки"(с) в одной транзакции с блокировками на всё время "проведения документа". Хотя я не уверен в Вашем понимании слова - "все". Это для всех строк документа? Если так - то по этому поводу я уже написал в данной теме... Ну, естественно, если в алгоритме производится "отдельное" чтение, с блокировкой, всех остатков по строкам документа для контроля "отрицательности", а потом выполняется реальное обновление БД, - то это не продуктивно. Но, для решения подобных задач, думаю, не следует уходить в сторону "раздолбайства" в части содержания БД. А Ваша статья к этому и призывает... :-(
Еще раз. Я привел пример того, что будет с остатками при использовании Вашей методы в (12) сообщении. Это так?
37. Ийон Тихий (cool.vlad4) 29.09.11 18:40
(36)READ COMMITTED не даст даже считать данные пока не завершится транзакция. Так, что не получится в 12 пункт 1, что и должно быть. А про то, что он говорит больше похоже на READ_COMMITTED_SNAPSHOT - пишущие транзакции не блокируют читающих, и читающие транзакции не блокируют пишущих.
38. Владимир (hogik) 29.09.11 18:59
(37)
Ну, тогда, я ничего не понимаю в колбасных обрезках в СУБД. ;-)
"Read committed: ...в процессе работы одной транзакции другая может быть успешно завершена и сделанные ею изменения зафиксированы. В итоге первая транзакция будет работать с другим набором данных..."(с). Т.е., в моём примере из (12) сообщения три задачи прочли начальное значение остатков равное тройке, пока не произошло изменение этого количества из другой транзакции. И поехали вычислять остатки относительно этого количества. Для этого и требуется блокировка при чтении начальных остатков. Так?
39. Олег Филиппов (comol) 30.09.11 10:13
(38) hogik,
поехали вычислять остатки относительно этого количества
Вы ничего не понимаете не в логике работы СУБД, а в логике работы 1С. Остатки считываются, но не меняются это 2 разных таблицы в 1С, и блокировка остатков для изменения движений не требуется.
40. Олег Филиппов (comol) 30.09.11 10:19
(36) hogik, Вы так ничего и не поняли :(((( в моей статье НЕ ИДЁТ РЕЧЬ ОБ ИЗМЕНЕНИИ ЛОГИКИ РАБОТЫ С БД об этом у меня другая статья :). В статье идёт речь лишь о соответствии системы логике работы на предприятии. Если принято "раздолбайство" с отрицательными остатками, а в ИТ идёт "борьба с блокировками" то для нормальных людей это как-то не логично :).

P.S.
Я привел пример того, что будет с остатками при использовании Вашей методы в (12) сообщении. Это так?
Так не будет! Вместо Флуда в комментариях взяли бы и проверили.
41. Владимир (hogik) 30.09.11 16:38
(39)(40)
Олег.
В процессе общения люди задают вопросы друг-другу по двум причинам:
1) Хотят понять суть обсуждения.
2) Хотят понять понимание сути собеседником.
Я Вам задаю вопросы по второй причине... ;-)
И это не "флуд", а нормальный, учтивый (уважительный) диалог с собеседником. Конечно, можно было написать, как написано в (3) сообщении и влепить "минус" на публикацию. И я не делаю подобного по отношению к Вашей "другая статья"(с), т.к. там и говорить (комментировать) нечего. :-(
А, если говорить по этой статье и Вашим пояснениям в комментариях, то - это полная пурга. Ну, например, прочтите собственную фразу: "о "Новой логике проведения" - когда контроль остатков производится после записи движений документа. "(с) и сопоставьте с Вашей трактовкой этого алгоритма таблицей #3. А какое, вообще, имеет отношение контроль остатков, если, по Вашим утверждениям: "Остатки считываются, но не меняются "(с). Т.е., по Вашему мнению, всегда просматривается всё движение каждый раз для выяснения значения остатков? А вторая таблица существует для проформы. ;-) Ну, или она существует для "регламентного" пересчета. Но тогда зачем, вообще, говорить о самом понятии "остатки" в алгоритмах "проведения документов". И не важно - отключена проверка отрицательности или она включена. Остатки, то всегда не актуальные, пока их не пересчитают "регламентной" обработкой.
Ох. И т.д. ...
А по поводу: "принято "раздолбайство" с отрицательными остатками, а в ИТ идёт "борьба с блокировками" то для нормальных людей это как-то не логично :)"(с), то, думаю, имеет смысл уточнить - кого Вы, в данном случае, называете нормальными людьми... :-)
P.S. Олег. Послушайте совет старого человека. Перечитайте, пожалуйста, свою статью и наше с Вами обсуждения. И попробуйте, изложить мою "позицию". Есть такой прием, когда собеседники не понимают друг-друга из-за того, что разговаривают о разных "вещах". Частенько это помогает избежать "мордобития"...
42. Олег Филиппов (comol) 30.09.11 17:28
(41) hogik,
Послушайте совет старого человека

Вы узко мыслите, вы так и не можете понять что происходит внутри 1с. В комментариях к моей другой статье человек достаточно чётко написал как на практике происходит - если вам лень читать теорию прочитайте хотя бы что он пишет. Сама таблица остатков не меняется в 1с. Меняется таблица движений, собственно моя таблица 3 абсолютно корректна.
43. Ийон Тихий (cool.vlad4) 30.09.11 18:03
Вы узко мыслите, вы так и не можете понять что происходит внутри 1с.
Терзают смутные сомнения, что так вы никому ничего не объясните. Стоит написать вводную(но не от слова вода;-)) статью. Тезис, основная мысль, ввести используемые термины и сокращения(что б не прыгать потом с блокировок БД на блокировки 1С), ну и т.д. Вы это знаете получше меня. Всем будет интересно.
44. Владимир (hogik) 30.09.11 18:42
(42)
Олег.
Считаю Ваше (42) сообщение хамским. Мы, вроде, обсуждаем 1С и СУБД, а не узость мышления и понятливости собеседника.
Но, переходя на личности. Увы... :-(
Ваша фраза: "Сама таблица остатков не меняется в 1с."(с) - полный бред.
"Регистр накопления остатков состоит из двух таблиц: таблицы движения и таблицы итогов. В таблице движений хранятся записи, которые либо вводятся пользователем вручную, либо генерируются в процессе проведения документа или исполнения обработки. Таблица движений имеет следующую структуру: 1. Период 2. Регистратор 3. Номер строки 4. Вид движения 5. <Измерения> 6. <Ресурсы> 7. <Реквизиты> В таблице итогов хранятся остатки в разрезе всех измерений с периодичностью месяц, на начало месяца. Временной интервал, за который хранятся остатки, ограничивается установкой периода рассчитанных итогов. Период рассчитанных итогов указывается как последний день месяца, по который рассчитаны итоги. То есть если период рассчитанных итогов равен 31.07.2004, то итоги будут рассчитаны по 01.08.2004 включительно. Кроме того, в таблице итогов отдельно хранятся актуальные итоги. Таблица итогов имеет следующую структуру: 1. Период 2. <Измерения> 3. <Ресурсы> Если период рассчитанных итогов равен 31.07.2004, а самое раннее движение было сделано 02.05.2004, то итоги будут хранится за следующие периоды: 01.06.2004, 01.07.2004, 01.08.2004 и актуальные итоги."
http://1c-wiki.ru/wiki/index.php?title=%D0%A0%D0%B5%D0%B3%D0%B8%D1%81%D1%82%D1%80_%D0%BD%D0%B­0%D0%BA%D0%BE%D0%BF%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F&printable=­yes
45. Олег Филиппов (comol) 30.09.11 23:34
(44) hogik, ладно, закроем вопрос - если из поста выше вы не сделали правильных выводов - всё равно не поймёте. Только не надо больше писать комментариев о том "как же тут сильно я не прав" чтобы людей не смущать теоретическими изысканиями. Я просто проверяю на практике в таких случаях - на практике всё работает именно так как надо и никаких нарушений целостности и конфликтов :)
46. Олег Филиппов (comol) 30.09.11 23:36
(43) cool.vlad4, Сорвался в принципе конечно надо просто понятнее писать... я хотел сократить статью только до практических рекомендаций, теоретические изыскания оставить по ссылке для желающих... мне на дали модераторы :).
47. Владимир (hogik) 03.10.11 02:47
Для читателей, которые будут пытаться разобраться в "публикации" и комментариям к ней.
В таблице #3 описана последовательность действий:
Начало
Списание с остатков
Блокировка
Чтение остатков
Завершение
На самом деле рекомендовано так:
"В самом конце транзакции в явном виде записать движения по тем регистрам, которые требуют контроля остатков. Для наборов записей этих регистров следует установить опцию "БлокироватьДляИзменения" в значение ИСТИНА. ... Именно в этот момент времени будет установлена блокировка остатков регистра по данному набору значений измерений. "(с) [ссылка в конце]
Т.е. последовательность действий, примерно, вот такая:
Начало
............ (другие действия)
Блокировка
Списание с остатков
Чтение остатков (если нужен контроль "отрицательности")
Завершение
И она (блокировка) ВСЕГДА должна накладываться, т.к. служит не только для проверки остатков, но и для корректной записи движения по регистрам в части "итоговых" данных.
Повторю своё утверждение: "и отрицательные остатки должны быть верными, хотя и отрицательными"(с) И это никак не связано с тем, что "вы продаёте булочки или шариковые ручки"(с).
P.S. Очень странно, что Гилёв Вячеслав (gilv) дал положительную оценку данной "публикации", написав вот эту статью: http://gilev.blogspot.com/2010/07/1_23.html
48. Иван Фотиев (photiev) 03.10.11 09:41
А нт ли диагностической обработки, чтобы проверить насколько правильно установлены блокировки?
49. Олег Филиппов (comol) 03.10.11 10:50
(47) hogik, Вы опять за старое :). Вы не понимаете - управляемая блокировка НЕ ИМЕЕТ НИКАКОГО ОТНОШЕНИЯ к методике записи движений и итогов в 1С. В типовых конфигурациях 1С (в т.ч. в УТ) если посмотрите упрвляемые блокировки есть только на несколько регистров (товары на складах и взаиморасчеты) по остальным их нет. Вы так и не сможете сложить в голове полную картину если будете читать только отдельные посты и статьи.
50. Олег Филиппов (comol) 03.10.11 10:54
(48) photiev, Я думаю её и не получится сделать... Блокировки должны быть привязаны к бизнес логике прикладного решения. Т.е. Если у вас производится контроль остатков и вам важно чтобы в "-" никто не при каких условиях списать не мог - блокировка должна быть. В типовых это обычно РН "товары на складах" и "Взаиморасчеты". Чтобы проверить правильность - просто точку останова посьавьте в одном сеансе в обработке проведения (где-нибудь в конце), а в другом попытайтесь списать то же самое... должно повиснуть на блокировке. Может конечно и получится для этого обработку сделать... но как у меня пока нет идей :(
51. Виталий (nafa) 03.10.11 10:59
Статья классная, но вот посылка
[quote]Если у вас в базе менеджер имеет право провести документ вне зависимости от того есть товар(деньги) на остатках или нет, зачем вам тогда блокировки?[/quote]
на мой взгляд нуждается в уточнении
Итак ситуация:
1. Товара на складе "стратегический запас", т.е. столько, что в минус они гарантированно НИКОГДА не уходят в минус.
2. Работают 2 пользователя с полными административными правами (например главбух и финдир)
По логике статьи, блокировки не нужны.
Однако, не стоит забывать, что учет может вестить по фифо/лифо и требуется распределение по партиями. И хотя общий запас товара многократно превышает расход, но остатки по отдельным партиям то могут быть маленькие. Отсутствие блокировки приведет к двойному списанию с одной и той же партии.
А вот если списание идет "по средней" то соглашусь с автором, что вполне реально подумать об отказе от блокировок.
52. Олег Филиппов (comol) 03.10.11 11:58
(51) nafa, Если почитать рекомендации 1С, то там галочка "списывать партии при оперативном проведении" документов ставится только если в базе работают только 2 пользователя главбух и финдир, а для регламентного пересчета блокировки точно не нужны.
53. Виталий (nafa) 03.10.11 12:25
(52)
Я не говорю, что проблема возникает во всех ситуациях. Я говорю о том, что если нет контроля остатков это не значит что не нужны блокировки.
Относительно отдельного списания партий - да, если такая технология (партии отдельно списывать) применяется, то согласен, описанной мной проблемы нет. Но
1. Ее (раздельное списание) применяют не все, так как она решает проблему производительностив в ущерб качеству отчетов.
2. Касается только оперативного проведения.
3. Конфигурация может вообще не предусматривать отдельного регистра для партий (один регистр остатков и в нем реквизит партия или аналогичный). (Мы же не только типовые рассматриваем)
54. Владимир (hogik) 03.10.11 17:21
(49)
Олег.
Вы в своей статье написали:
"...паразительно как много людей об этом не знают."(с)
Представьте себе, что я отношусь к этим МНОГИМ. :-)
Далее, Вы даёте "ценную" рекомендацию:
"установить управляемые блокировки там где это нужно"(с)
В Вашем понимании это:
"только там где производится контроль остатков"(с)
Далее Вы пишете, что:
"Браком и пересортом по человеческой вине вы теряете в сотни раз больше, чем могли бы в случае одновременного проведения двумя пользователеями двух одинаковых докуметов отгрузки."(с)
Из этой фразы, лично я, делаю однозначный вывод: на остатках будут получаться произвольные числа. Пытаюсь, разобраться. Смотрю таблицу #3. Вызывает удивление. Спрашиваю. Получаю от Вас ответ:
"остатки просто спсываются произвольным образом (речь не идёт о партиях)"(с)
Пытаюсь дальше спрашивать. И получаю от Вас информацию:
"Остатки считываются, но не меняются "(с).
Но, тогда, зачем говорить о блокировках, если ничего не меняется.
Дык, может меняется? ;-)
А теперь ВНИМАТЕЛЬНО читаем (53) сообщение...

P.S.
Т.е. Ваша "статья" сводится к одной "мысли":
Если блокировки "мешают" системе работать быстро, то надо убрать ВСЕ лишние блокировки. И оставить только нужные.
Думаю, об этом многие люди догадываются... :-)
55. Олег Филиппов (comol) 03.10.11 18:26
(53) nafa, Нуу в варианте если мы используем РН "товары на складах" с измерением "серия", при этом при оперативном проведении списываем партии, то по хорошему и остатки контролировать нужно бы в разрезе партий... А без блокировки, естественно возможны "минуса" по партиям.. кто же спорит... только вот с блокировкой, да ещё и партии списывать оперативно... это уже по ситуации в бизнесе зависит.. что нам важнее.. оперативность или точность.
56. Олег Филиппов (comol) 03.10.11 18:34
(54) hogik,
Т.е. Ваша "статья" сводится к одной "мысли":
Если блокировки "мешают" системе работать быстро, то надо убрать ВСЕ лишние блокировки. И оставить только нужные.


Да, только моя статья вкладывает больше смысла в понятие нужные.

С тем что технические детали понять достаточно сложно я согласен, попытался объяснить как мог; кто-то всё-таки понял, кто-то попытался разобраться и понял, кто-то попытался разобраться и не понял. Я тоже понял что мне есть над чем работать в плане ясности изложения мыслей.. :)
57. Виталий (nafa) 03.10.11 20:33
(55)
comol пишет:
Нуу в варианте если мы используем РН "товары на складах" с измерением "серия", при этом при оперативном проведении списываем партии, то по хорошему и остатки контролировать нужно бы в разрезе партий...

Только не "серия", а "ДокументПоступления".
Разница простая.
"серия" - это то, что определяется свойствами товара конкретной серии (маркировка, дата производства, срок годности и т.п.). Она как раз в типовых имеется. При отгрузке товара в зависимости от технологии работы склада серия либо указывается в заказе и кладется соответствуюшая, либо не указывается, кладется любая, фиксируется в наборном листе, далее вводится в реализаци то что положили. В типовых это измерение как раз есть в остатках.
Данная серия определяется человеком а не компьютером и от блокировок не зависит. Контроль с блокировками нужен на этапе резервирования товара дабы не зарезервировать один и тот же товар дважды. Блокировки на этапе отпуска нужны в том случае, если товар выписывается без резервирования - т.е. сразу реализацию и товар кладовщик собирает по накладной.
"ДокументПоступления" - расчетное понятие для определения себестоимости товара, когда на складе есть товар со всеми одинаковыми характеристиками но разной себестоимостью. Тут остатки не столько контролировать надо, сколько просто правильно определять дабы не списать 2 раза с одного Документа поступления. В УТ вынесено в отдельный регистр.
58. Владимир (hogik) 03.10.11 20:54
(56)
"мне есть над чем работать в плане ясности изложения мыслей"(с)
Олег.
Не надо над этим работать. ;-) Вы совершенно ясно (и понятно) излагаете свои мысли. Лично меня, смущает само содержание этих мыслей (не отсутствие!!!). Например, нет такого выбора "оперативность или точность"(с). Думаю, допустим выбор: "оперативность или полнота"... А всё остальное и есть - "раздолбайство" и неуважение к покупателям, складским работникам, пользователям ИС, деньгам владельца и т.д.
Но это, сугубо, моё личное "восприятие" Ваших публикаций...
Всё! Спасибо за содержательную беседу и в этой теме.
Желаю успехов в ... ;-)
59. Олег Филиппов (comol) 04.10.11 10:01
(57) nafa, Я написал "Серия" потому что это наиболее привычный метод организации партионного учет "с явным" указанием партий в типовых конфигурациях. Серии есть в каждом документе... есть кнопка "заполнить по сериям" и т.п. Обычно если решают вашу задачу в типовых - ими пользуются. А "документ поступления" в регистр - это уже существенная доработка... хотя и так люди делают :)
60. Олег Филиппов (comol) 04.10.11 10:06
(58) hogik,
По-моему заставлять пользователя по 5 раз проводить документ или ждать пару минут пока проведётся - "не уважение к пользователям, покупателям, складским работникам"
А покупка Oracle или ооочень крутого "железа" - "не уважение к деньгам владельца".

К сожалению, большинство ИТ-шников мыслит так же как вы - "ну меня учили, что транзакция и блокировка должна быть" - "в учебнике так написано". И не могут взглянуть на проблему со стороны бизнеса "а что мне дороже - блокировка, или последствия её отсутствия".
61. Владимир (hogik) 04.10.11 15:44
(60)
Олег.
Я с Вами полностью согласен. Перечисленные Вами явления - абсолютное неуважение! А "ИТ-шников" совершенно верно учили, "что транзакция и блокировка должна быть"(с) Но, им, видимо, забыли сказать, что время ИХ выполнения должно быть соответствующее предметной области. И для этого "ИТ-шникам" надо РАБОТАТЬ, а не перекладывать "свои проблемы" на других людей... Но в "1С-ах" работать "ИТ-шникам" придется ООО-чень много, т.к. в архитектуре этих систем наличествует "конфликт" в подходе проектирования ИС "от документа" и "запросным ЯМД". Но это другая тема...;-) И, лично мне, она не интересна, "ввиду отсутствия присутствия" ;-) продуктов 1С-а в моей деятельности. Чего и Вам желаю... :-)
62. Alex AlexX (_iAlex) 04.10.11 15:57
Есть еще один аспект, зачастую ресурсы не соответствуют потребностям и из-за этого время блокировок растет и ИТ-шники ничего с этим поделать не могут, так как денег на другое железо не дают
63. Владимир (hogik) 04.10.11 16:17
(62)
А где хваленная "масштабируемость" 1С-ов? Или она заключается только в возможности перенести систему на более мощное железо? :-) Вот пример. Разработчики "1С 7.7" рекомендуют переходить с DBF-ной версии на SQL-ную при количестве пользователей около 5 человек. По моему (печальному) опыту общения с 1С-ами - всё это решается и без перехода на SQL-ную версию. И без сверток БД (полный бред!!!). Но для этого пришлось ВСЁ переделать... :-( И система обслуживает 50-75 пользователей, 11 лет, на "сервере" по уровню мощности WS. Проблем и причин для смены системы - не имеется... :-)
64. Олег Филиппов (comol) 04.10.11 16:24
(62) _iAlex, Ну хоть кто-то понял о чём я...
65. Олег Филиппов (comol) 04.10.11 16:28
(63) hogik, Да с масштабируемостью то всё в порядке... свёртки это конечно жесть... как раз про них статью дописываю... удивительно как много людей до сих пор их делает.

Проблемы 1С с жуткой нестабильностью работы... неотлаженностью и неотработанностью некоторых механизмов, отчасти это диктуется ориентацией на россиийский бизнес (возможность работы задним числом, возможность работы без контроля остатков).

То что у вас нет 1с заметно, поэтому и просил не писать постов. Некоторые "фичи" или "баги" становятся понятными только после долгой практики с ними борьбы.
66. Виталий (nafa) 04.10.11 17:02
(63)
hogik пишет:
По моему (печальному) опыту общения с 1С-ами - всё это решается и без перехода на SQL-ную версию. И без сверток БД (полный бред!!!). Но для этого пришлось ВСЁ переделать... :-( И система обслуживает 50-75 пользователей

А можно поподробнее про базу 7.7 на 75 рыл и без скуля?
67. Владимир (hogik) 04.10.11 17:05
(65)
Олег.
Я писал только об общих вопросах ИС. И подсовывал Вам примеры из 1С-ов... ;-)
Уверяю Вас всяких "фичей и багов" хватает в любых системах. Но, на мой взгляд дилетанта, надо стараться устранять причину, а не следствие ( http://infostart.ru/public/92685/ )
P.S. Вы написали: "Ну хоть кто-то понял о чём я..."(с)
Уверяю Вас, что я с первой буквы Вашей публикации понял о ЧЕМ и ПОЧЕМУ Вы говорите. :-)
Но "понимать" и "соглашаться" - это разные явления. Не надо думать, что если собеседник понял, то сразу и согласился с позицией собеседник.
68. Владимир (hogik) 04.10.11 17:49
(66)
"А можно поподробнее про базу 7.7 на 75 рыл и без скуля?"©
Можно. ;-) Всё очень просто.
Началось всё в 2000 году с моим появлением в фирме (оптовая и розничная торговля). Две территории. На одной самопальная система "до уровня" пробивки чеков на ККМ из этой системы. На другой - "1С 7.7" на три пользователя используется для распечатки выходных документов (как текстовый редактор). Поставлена задача - сделать единую ИС. Номенклатура, к тому моменту - 35000 наименований (частично пересекающаяся). Ну, и начал делать. ;-) Увы, на 1С... :-(
Сначала отказались от регистров, "монолитного" документа, понятия проведения документов, оси времени, точки актуальности, хранения итогов НА, монопольных регламентных работ и т.д. Т.е. от 1С осталась только заставка. :-)
Далее система стала расширяться по количеству пользователей. Решили проблему 1 гигабайта на системном уровне. Решили проблему 2 гигабайт на уровне схемы базы данных и методов работы с ней. Сделали собственную распределенную БД (на уровне объектов 1С) для выделения розничного зала на отдельные "сервера" и повышения отказоустойчивости (у нас режим работы 24х7). По мере увеличения участков АвтоМехАнизации появилась тенденция к увеличению количества "серверов". А т.к. в "центральном" сервере уже работало до 30 человек, и на DBF-ах сильно страдала надежность, то поменяли "движок" на клиент-серверную СУБД. Со второй попытки ;-)
Имеем интерфейс к БД 1С-а. Пишем "автономные" задачи на Си.
Ну, вроде, и все рассказал. Последние три года ничего крупного не делаю...
P.S. Попытался рассказать кратко. Именно, в аспекте "без скуля"(с) Т.к. других деталей - масса.
MaxDavid; nafa; +2 Ответить 7
69. Сергей Рудаков (fishca) 04.10.11 17:56
(68) Напиши статью, очень хотелось бы видеть что и как делалось, подробно, пожалуйста!
70. Владимир (hogik) 04.10.11 18:23
(69)
"Напиши статью"(с)
А кому это может понадобится? Концептуально, нового мы ничего не сделали. Думаю, более полезным будет изучать КАК и ЧТО делается в ИХНИХ системах. Универсальные решения я "опубликовал" на данном ресурсе. Единственно, что можно было бы написать - это, примерно, о роли реляционных СУБД с запросным ЯМД в "наших" задачах. Т.к. этой темой занимаюсь очень давно. Но, я уже "проверил" интерес сообщества к этой теме, пару лет назад. Получилось угрюмо и печально. ;-) Да и написано на эту тему уже очень много и, гораздо лучше, чем я это сделаю.
71. Игорь Исхаков (Ish_2) 04.10.11 18:38
(70) Ага. Получилось угрюмо и печально.
Вспоминаю заминусованную тему (-5 !) что-то вроде "как я не понимаю нарастающий итог".
Основная мысль которой - "можно не так".
Кто только не пытал Владимира "Скажи как ?!!".
Ответ был только один : "не так !".
Максимум что удалось вырвать кроме длиннющих размышлизмов :
это простенький код от Владимира (перебор в цикле строк таблицы "аля клиппер 87").
После чего стало всё понятно и скучно.
ZLENKO; comol; +2 Ответить 1
72. Владимир (hogik) 04.10.11 19:05
(71)
Игорь.
У Вас есть риск отравиться собственным ядом. ;-)
Неужели не очевидно, что проблема, обсуждаемая в данной теме, "порождается" применением запросов и построение системы "от документа" в реляционной модели?
Для примера, у меня "движение по т.н. регистрам" и проверка "отрицательности остатков" делается вызовом одной функции примерно такого вида: R=F(Измерение1,Измерение2...,Количество,ЕдИзм)
И она выдаёт значение R - информацию об "отрицательности".
Вызывается на каждую строку "документа"(в терминах 1С-а).
И не блокирует ничего, кроме ОДНОЙ строки (хозяйственной операции) только на момент её модификации. А не всего состава "документа", т.к. и документа (как многострочного агрегата) у меня в системе нету. Замечу, как и во многих ИХНИХ системах.
А что касается Вашей фразы "Максимум что удалось вырвать"(с) - замечу, что перед этим "простеньким кодом"(с), я долго пытался повернуть Ваши мозги в "нужном" (для содержательного разговора) направлении. И получал от Вас ответ, типа "Не соглашаюсь". И как можно в таком режиме разговаривать...
P.S. Но, я помню Ваше предложение решать поиск отсутствующих номеров документов запросом, а не циклом. Было очень интересно и смешно. ;-) И все остальное Вы предлагаете делать именно таким образом. Через з...
73. Олег Филиппов (comol) 05.10.11 00:25
(68) hogik, Я конечно всякие, извиняюсь за выражение, извращенства, видел, но такого.... Собственно когда людям не чем заняться бывает и такие явления появляются... бывает на delphi что напишут, бывает сделают Web интерфейс к SQL-ю... на западе тоже такое было.... лет 50 назад :)
ugroblin; red80; +2 Ответить 1
74. Олег Филиппов (comol) 05.10.11 00:37
(72) hogik,
Вызывается на каждую строку "документа"
"1С Специалист" вы бы не сдали :). Очень.. ммм... продуктивное решение, правильно, зачем заморачиваться с группой записей - можно по одной их обработать, ну чуть погоняем данные с клиента на сервер - не беда, сетевые интерфейсы быстрый, "и пусть весь мир подождёт".

Для примера, у меня "движение по т.н. регистрам" и проверка "отрицательности остатков" делается вызовом одной функции примерно такого вида: R=F(Измерение1,Измерение2...,Количество,ЕдИзм)

Если бы такое делалось в "ихних" системах... мы бы наверное ещё не шагнули дальше больших ЭВМ System 360 :)
75. Виталий (nafa) 05.10.11 01:00
(74)
comol пишет:
Цитата
Вызывается на каждую строку "документа"
"1С Специалист" вы бы не сдали :). Очень.. ммм... продуктивное решение, правильно, зачем заморачиваться с группой записей - можно по одной их обработать, ну чуть погоняем данные с клиента на сервер - не беда, сетевые интерфейсы быстрый, "и пусть весь мир подождёт".

Должен высказаться в защиту hogik, так как самому пришлось такое делать (резервирование по факту ввода строки в документ). Причина простая. Ситуация:
Менеджер разговаривает с клиентом по телефону, формирует заказ. Получает от клиента запрос на 100 ед товара, подтверждает, переходит к следующей позиции. Доходит до конца, начинает проводить документ и выясняется, что в это время кто-то другой провел еще заказ и товар зарезервирован другим, т.е. 100 ед нет, есть только 20. Согласитесь, что перед клиентом это выглядит очень некрасиво. Ничего не оставалось делать, как резервировать товар сразу по факту ввода строки в документ. (Можно конечно нажимать "провести" после ввода каждой новой строки, но это еще большая нагрузка на сервер так как потребует пересчета резервирования всех строк документа а не только последней).
76. Владимир (hogik) 05.10.11 01:19
(74)
Олег.
1) "1С Специалист" вы бы не сдали :). "(с)
И не собираюсь. :-) Т.к. их представление об ИС (в части назначения СУБД) еще не "докатилось" до IBM/360. Они только-только начали понимать, что такое перфокарта.
2) В (75) сообщении всё написано. Добавлю, только к этому, что пример моей функции не использует запросов. И в нашей системе, сетевая передача информации не является узким местом. В случае использования "запросного" алгоритма при "проведении документа" по сети передаётся больше информации. Примите это на веру. Уж очень лениво заниматься арифметикой. Считали и проверяли это многократно. Есть алгоритмы, где использовать запросы эффективнее, там мы их и используем. А "ввод" данных в БД - это не тот случай...
MaxDavid; +1 Ответить
77. Алексей Коробов (WiseSnake) 05.10.11 01:34
ИМХО не все так просто как описано в статье... На эту тему уже много написано на ихним языке и про ихние системы...
Если я правильно понял суть вопроса, то Вы блокируете только те регистры которые связаны с остатками... остальные объекты остаются без контроля... Тогда простой пример: 2 человека пишут один и тот же документ\справочник\и т.д. с разными данными, который не относится к остаткам...хм.. что в итоге получится я не представляю... нет никаких гарантий целостности данных.

Далее пример: мы пишем приходник он к остаткам не имеет отношения, но двигает взаиморасчетам, по которым тоже необходимо вести контроль(например) и в итоге проводится реализация которая превысила долг контрагента... то есть надо еще настраивать блокировки и на взаиморасчеты... в итоге получается что для нормальной настройки базы необходимо проделать огромный труд!

Еще раз повторюсь, что не все так просто!!!

P.S. возможно маленькая вероятность возникновения конфликтных ситуаций в базе, но эта вероятность зависит от очень многих факторов. И нет никакой гарантии что она не возникнет в самый неподходящий момент.
78. Владимир (hogik) 05.10.11 02:28
(73)
"извращенства"(с)
Олег.
Это называется - разработка системы. У меня специальность такая...
А Вы, как я понимаю, занимаетесь внедрением готовых систем.
И думаете, что эти "готовые системы" растут на полках магазинов. ;-)
79. Алексей Новоселов (a-novoselov) 05.10.11 08:45
(20)
Относительно 1С:
а)Блокировки данных при записи выполняются на уровне СУБД (+проверяется платформой).
б)Остатки в базе считаются и пишутся на уровне платформы.

Выводы:
а) Записать неверные данные в БД вы не сможете физически, никакие блокировки тут не при чем. Если вы попробуете, например, дважды записать в регистр запись с повторяющимся набором всех измерений, то вывалится ошибка SQL нарушение уникальности индекса и ничего не выйдет. Т.е. кривые данные с точки зрения СУБД (повторяющиеся абсолютно одинаковые строки в таблице и т.п.) вы записать впринципе не сможете. Еще в платформу встроен механизм проверки корректности данных, ведь в файловом варианте она сама является сервером СУБД.

б) Если платформа что-то накосячит с записью остатков (что маловероятно, т.к. алгоритмы максимально протестированы и отптимизированыи и используются еще с 7.7 а то и раньше), то есть регламентная процедура "Пересчет итогов регистров накопления". Блокировки тут устанавливает тоже платформа и от конфигурации и типа блокировок в конфигурации абсолютно ничего не зависит.

Итог: На уровне конфигурации вы можете накладывать блокировки только на чтение данных, т.е. прочитали - заблокировали - начали что-то писать. На целостность данных это никак не влияет. Просто другая транзакция не сможет прочитать те же данные. А так как на уровне конфигурации вы пишете только движения документа, то даже без всяких блокировок остатки будут верными. Просто без блокировки во время чтения данных внутри транзакции СУБД может показать возможно неверный результат запроса, если есть незавершенные транзакции, работающие с этими данными и эти транзакции завершаться успешно. Следовательно если контроль остатков внутри транзакции не нужен, то и блокировки никуда не уперлись.
80. Виталий (nafa) 05.10.11 09:10
(79) Я бы сказал по-другому - если данные какого-то регистра ни в одном документе в транзакциях проведения на чтение не используются, то блокировка этого регистра при проведении не нужна.
81. Олег Филиппов (comol) 05.10.11 11:07
(78) hogik, Ну это вам в Oracle или Microsoft, ещё в SAP можно попробывать... Покажите им свою разработку - они вас примут разработчиком :). Разработка системы это когда 10 экстра профи месяц занимаются планированием архитектуры, потом к ним добавляется ещё описание интерфейсов и объектной структуы, потом кодирование ещё несколько десятков человек, потом документирование всего этого... Всё это сопровождается многомиллионными инвестициями, при этом даже близко приблизиться к 1С получится едва ли... не говоря уже о других системах...
82. Олег Филиппов (comol) 05.10.11 11:15
(77) WiseSnake,
1) Если 2 человека пишут один и тот же документ/справочник - существуют "объектные" блокировки на уровне платформы :), от которых ну никак не избавишься
2) Целостность данных поддерживается на уровне СУБД - естественно при записи данные блокируются, об этом уже писал выше в комментах - почитайте
3) Ну да, если хотите чтобы "-" не мог возникнуть то нужно ставить блокировку при чтении взаиморасчетов. Но это не огромная работа. Сколько вы ещё знаете таких примеров. В УТ 11 по-моему блокируются как раз только товары на складах и взаиморасчеты... и всё - 10 строчек кода :)
83. Алексей Коробов (WiseSnake) 05.10.11 14:03
(82)1,2. Это радует. Не прочитал, не работал просто с управляемыми блокировками...
3. Но проблема все равно не уходит:
Я знаю что надо контролировать: остатки, взаиморасчеты + контроль числа дней задолженности, остатки по партиям и еще много чего, лень вспоминать.
Все это надо обдумать как делать ведь, как я понимаю суть вашего примера в том что блокируется на чтение регистр до момента завершения записи этого регистра (а не до конца записи всех данных документа, иначе это была бы почти обычная блокировка как сечас), потом освобождается.
В этот момент и может произойти путаница: Пример(упрощенный чисто для примера конфликта):
1. Реализация1 блокировка остатков, контроль пройден успешно.Запись
2. Реализация2 блокировка остатков, контроль не пройден из за списания Реализации 1. Отмена проведения.
3. Реализация1 блокировка взаиморасчетов, контроль не пройден. Отмена проведения.
....
В этом примере Реализация 2 должна была быть проведена.
То есть надо блокировать до конца записи всего документа но это шило на мыло, или переделывать проведение документа, сначала двигать "важные" регистры и блочить до конца их записи.

P.S. ну в общем и целом это здоровая оптимизация, только ИМХО надо очень хорошенько все продумать, и поработать(все еще остаюсь при своем мнении что это большой труд)!
84. Ийон Тихий (cool.vlad4) 05.10.11 14:11
(81) Не скажите, я видел (да и сам делал), простейшие учетные программки на том самом Delphi, к которому вы почему-то отнеслись с пренебрежением. Не у всех бюджет микрософта. И честно говоря не понял (74), потому как не понял (72).
85. Владимир (hogik) 05.10.11 16:51
(79)
Алексей (a-novoselov).
Я с Вашими "Выводы"(с):
а) Согласен.
б) Согласен. Но, с оговоркой. Регламентные процедуры призваны обеспечивать (исправлять) актуальность и достоверность "итоговых" данных для "учетных"/"отчетных" систем. Т.е. когда "итоги" используются значительно позже совершения ХО. Например, в бухгалтерских "учетах", АвтоМехАнизированных по принципу - а потом бухгалтер (специальный оператор) берет в руки бумажный документ и "заводит" его в базу данных. И в таких "системах" не проявляется "проблема" с блокировками и/или монопольным пересчетом итогов.
А с Вашим "Итог"(с) - не могу согласиться. Т.к. если "вы пишете только движения документа"(с), то и темы для разговора не существует. Мне представляется, что разговор идет об чтении записи с целью её изменения (суть самого понятия "итоги") несколькими процессами (сессиями 1С). И в этом случае блокировка (возможно и не средствами СУБД) записи - обязательна, если есть желание получить достоверные и актуальные данные.
(81)
Олег.
Я оказался прав - для Вас "готовые системы" растут на полках магазинов. :-)
И Ваша фраза "Разработка системы это когда 10 экстра профи месяц..."(с) подтверждает мою правоту. Т.к. в "Oracle или Microsoft, ещё в SAP"(с) это делается гораздо дольше. И делается на протяжении всей жизни и развития "проекта". И важным моментом таких "проектов" является возможность расширения функционала, дабы конечному пользователю не приходилось покупать и внедрять, уже, собственную систему каждый раз как только ТЕ разработчик поймут, что они ошиблись в самом начале своего "проекта". А 1С-продуктам на это наплевать... ;-)
Что касается Вашей фразы:
"Покажите им свою разработку - они вас примут разработчиком :)."(с)
Неужели, Вы думаете, что за 38 лет общения с ЭВМ-ами, я занимался только ковырянием в 1С-е...
(84)
(cool.vlad4)
"потому как не понял (72)"(с)
Как!? Чего? Совсем? Всё? :-( :-( :-(
Если хотите, то давайте я попробую пояснить свой текст.
Видимо, я очень плохо изложил свои мыслишки...
86. Олег Филиппов (comol) 05.10.11 18:03
(84) cool.vlad4, Я тоже когда-то делал свою систему на Delphi для учета в автомастерской и торговлей автозапчастями :)... эх... были времена... потом на Access... потом часть из них на 1С перевёл.. а часть не знаю... может так и работают :). Но конечно я этим не горжусь как многие... скорее наоборот...
87. Олег Филиппов (comol) 05.10.11 18:08
(85) hogik, Да, бюджеты и количество народа конечно несравненно больше. Поэтому "русскими энтузиастами" должны бы руководить грамотные менеджеры проектов, а то и получается то что вы написали. Мне нравится то что 1С пытаются сделать... Просто есть понятие "Жизненный цикл" продукта, естественно есть методология, поэтому так сказать как вы "всё неправильно и нужно всё переписать" легко, а вот сделать :)))
88. Алексей Новоселов (a-novoselov) 05.10.11 18:11
(0) comol, вобщем я попытался доказать доказать Владимиру что-то, но не смог. Больше пытаться не буду, он прав потому, что его закостенелое мышление не переломить :)
89. Владимир (hogik) 05.10.11 18:40
(86)(87)
Олег.
Вы о чем?
Мы, вроде, обсуждаем Вашу идею выбора: "оперативность или точность"(с)
Возникают "смежные" вопросы - рассказываем свой опыт друг-другу, обсуждаем...
Еще раз, спрошу. Приведите, пожалуйста, таблицу последовательности выполнения операций с БД в случае обновления "актуальных итогов" при "проведении документа" с совокупными блокировками 1С+СУБД. Если там будет обеспечена "точность", то я соглашусь с Вашими предложениями из публикации. Ну, а если не будет обеспечена, то разбежимся - каждый со своим мнением на АвтоМехАнизацию. Идет?
90. Ийон Тихий (cool.vlad4) 05.10.11 18:44
(86) у меня нет гордости, я просто удивлен отношением к независящему от этого- языку Delphi. Язык как язык.
(89) Я не понял функцию R=F(Измерение1,Измерение2...,Количество,ЕдИзм) в контексте 1С, и чем данный подход отличается от традиционного.
91. Владимир (hogik) 05.10.11 20:10
(90)
"...в контексте 1С, и чем данный подход отличается от традиционного."(с)
Во всех 1С-ах считается, что наименьшей единицей "взаимодействия" с ИС является документ. Для документов без табличной части - это похоже на правду. ;-) А для документов с табличной частью - это глобальная ошибка в проектировании системы. Т.к. "хозяйственной операцией" (ХО) является одна строка таких документов. Если в ИС ставится целью учитывать документы, то - этот подход оправдан. Если ставится задача АвтоМехАнизировать деятельность, непосредственно, участников ХО, то он совершает не ХО над документами, а ХО "размером" в одну строчку документа. На мой взгляд, в ИС следует "учитывать" (фиксировать) ХО, а не документы. Способы реализации такого подхода могут быть различными - как в выражении предметной области, так и в "программном" уровне.
Функция R=F(Измерение1,Измерение2...,Количество,ЕдИзм) выполняет фиксацию в БД одной ХО. И блокировка "накладывается" только на этот момент. Реализация функции зависти от модели СУБД. В моем случае:
Логическая блокировка "измерения".
Поиск по ключу и чтение итога (остатка).
Вычисление нового значения итога.
Проверка "отрицательности" (если требуется).
Запись нового значения "движения".
Обновление итоговой записи.
Снятие блокировки.
Т.е. всё очень примитивно с точки зрения общения с СУБД, в части блокировок. ;-)
Интересней логика "управляемых" блокировок в системе в целом.
Типа - иерархическая модель... :-)
MaxDavid; lustin; +2 Ответить
92. Владимир (hogik) 06.10.11 00:04
(88)
Алексей (a-novoselov).
Вы не "попытались доказать"(с), а изложили НЕЧТО:
1) "блокировки только на чтение данных,"(с) - допускаю.
2) "прочитали - заблокировали - начали что-то писать."(с) - странно.
3) "другая транзакция не сможет прочитать те же данные"(с) - легко!!!
Для успешного выполнения утверждения #3, требуется в #2 сначала заблокировать, а потом читать. ;-)
93. Олег Филиппов (comol) 06.10.11 00:54
(90) cool.vlad4, Тем что по каждой строке остаток вычисляется отдельно :)
94. Владимир (hogik) 06.10.11 02:07
(93)
Меня уже боитесь спрашивать? ;-)
Там нет строк. :-)
А Вы думаете запросная СУБД делает иначе?
Табличку давайте!
Хватит людям зубы заговаривать.
95. Владимир (hogik) 06.10.11 03:25
(93)
Олег.
Табличку лучше представить для одной строки документа и одной сессии. А "подвигать" её во времени относительно другой, аналогичной, таблички - думаю, не составит труда для читателей данной темы. Ага? Ждём-с...
96. Алексей Новоселов (a-novoselov) 06.10.11 07:57
(92) В #3 согласен, что для успешного выполнения этого условия необходимо данные заблокировать. Но это условие вовсе не обязательное, если нет контроля остатков.
97. Олег Филиппов (comol) 06.10.11 15:13
(94) hogik, Мне, я думаю, вас не о чем спрашивать.
Разве что что такое
запросная СУБД
:).
А про уменьшения клиент-серверного взаимодействия вы видимо не слышали...
98. Владимир (hogik) 06.10.11 16:12
(96)
"это условие вовсе не обязательное, если нет контроля остатков"(с)
Алексей (a-novoselov).
Контроль остатков (итогов) есть ВСЕГДА. А "проверка отрицательности" может и не быть. И весь вопрос ГДЕ, КАК, КТО, КОГДА, ПОЧЕМУ требуется, именно, КОНТРОЛЬ, а не ПРОВЕРКА.

(97)
"Мне, я думаю, вас не о чем спрашивать"(с)
Олег.
Вы напрасно тратите свое время и силы на доказательство моей глупости. Я уже признался, что я полный идиот и ничего не понимаю. Как начал разрабатывать ИС+СУБД в начале 70-х годов так ничего и нЭпонимаю... :-) А больше всего, я нЭпонимаю - за ЧТО мне, все эти годы, платят деньги. :-)
Табличку, то нарисуйте...
Ведь данную тему не только мы с Вами читаем!!!
Вы, вроде, статью написали, а не оправились в блоге?

По поводу "запросных" СУБД: http://ru.wikipedia.org/wiki/DML
P.S.
У меня к Вам предложение. ;-)
Давайте поменяем аннотации к Вашим статьям на, примерно, такой текст:
"Если Вы, случайно, купили "1С 8.х" вместо текстового редактора и ОНА мешает Вам работать своими блокировками. То Я сейчас Вас научу как ЕЁ превратить в текстовый редактор".
99. Олег Филиппов (comol) 06.10.11 18:02
(98) hogik, Да ещё и не за это платят деньги в некоторых организациях. Таблички у меня все адекватные. Приходится выбирать между доступностью понимания и методологической правильностью изложения.

По поводу "запросных" СУБД: http://ru.wikipedia.org/wiki/DML
Ну и где там понятие "Запросная СУБД", а какие из низ "Не запросные"? :))

"Если Вы, случайно, купили "1С 8.х" вместо текстового редактора и ОНА мешает Вам работать своими блокировками. То Я сейчас Вас научу как ЕЁ превратить в текстовый редактор".
Вынужден вас огорчить :)... текстовые редакторы, как и табличные со времён 70-х годов ушли далеко вперёд. И там тоже есть блокировки... и более того, они даже не табличные :) поэтому их будет больше чем в 1С в этом случае.
100. Владимир (hogik) 06.10.11 18:20
(99)
Олег.
Я призываю Вас перестать доказывать мою глупость. Доказывайте, пожалуйста, свою "умность". Таблички у Вас Не"адекватные" и с ошибками. Еще раз - приведите табличку описанную в моём (89) сообщении. Мы с Вами занимаемся бла-бла уже две недели. Пора закругляться...
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа