Здравствуйте! Я готовлюсь к сдаче Специалиста, и сейчас пробую решать задачи с использованием транзакционных блокировок.
Ни в коем случае не воспринимать как учебный материал, это моё видение принципов на начальном этапе освоения управляемых блокировок. Вероятнее всего оно ошибочное.
Я хотел бы прояснить принципы, которыми следует руководствоваться, при проектировке системы с самого начала используя управляемые блокировки.
А именно взаимоотношения между документами разных типов, отчетов использующих одни и те же регистры в разных режимах.

Я исхожу из проблем, которые призваны решать блокировки.
1. Потерянное обновление  
Может возникнуть при записи одного и того же объекта.
Решается установкой Исключительной блокировки на данный объект при записи.

2. Грязное чтение
Может возникнуть при чтении данных объекта, который в это время записывает другой процесс.
Решается установкой Разделяемой блокировки на считываемые данные.

3. Неповторяемое чтение.
Может произойти, если в одной транзакции данные с одних и тех же источников считываются не один раз, и между этими считываниями другая транзакция может изменить эти данные.
(Кто-нибудь считывает данные в одной транзации раза?)
Лечится наложением на читаемые данные Исключительной блокировки.

4. Фантомные вставки.
Ситуация может возникнуть при формировании отчета, использующего определенные записи (регистра накопления например),  в это время появляются новые записи, и отчету опять зачем-то считывает всю таблицу, и получает другой результат.
Лечится...хз... Получается разделяемой блокировкой на всю таблицу, чтобы док не смог наложить исключительную - но на какие записи? Записей то нет. (Впринципе всё равно так как два раза анализировать одну и ту же таблицу в одной транзакции вряд-ли придется)

Из этого я могу заключить - Накладывать разделяемые блокировки на все, что читаешь, а исключительные на всё что пишешь.

К примеру при проведении простого документа Приходная накладная, я делаю условие - где узнаю Перепроводится или проводится в перевый раз.
Если перепроводится накладываю транзакционные блокировки на существующие записи регистра по регистратору, потом их удаляю и записываю новые (движения) - так?
если проводится в первый раз то ничего не блокирую - так как нечего блокировать? (Это кстати и может привести в фантомным вставкам).

Или предыдущий абзац это задача объектных блокировок? Как разграничить проблемы которые решают объектные и транзакционные блокировки?

(0) предлагаешь тут писать диссер?

разруливай, описывай как и что делаешь - я буду следить за тобой

(0)Медитируй:

1. http://www.ravepoint.narod.ru/aticles/tecnology/4techinf/4_1common/4_1_2.htm
2. http://www.ravepoint.narod.ru/aticles/tecnology/2methodics/2_3.htm

Ооо! Это зачетное курево! Спасибо! Буду вникать.

хорошие вопросы :)

+(2)
можно еще вот это
http://www.ravepoint.narod.ru/aticles/tecnology/2methodics/2_4.htm

(0)А что на спеца теперь задачи идут на блокировки?

Задания обязательно должны быть сделаны с использованием управляемых блокировок.

Управляемые блокировки решают последние 3 проблемы. Накладывать блокировки на объекты в рамках задач на спеца не нужно. Да и в реальной практике встречается крайне редко, сама система отлично справляется с этой задачей.

to 8 почитайте свежие требования (2-я часть 3-ий абзац)
Хотя конечно заблокировав таблицу остатков при проведении расходной думаю устроит экзаменующих, но я буду использовать Postgres, и хотелось бы разобраться сразу, а не потом когда прижмет.
После курения манов от Рэйва.

Во-первых по проблемам(те что в сабже по номерам), 3-я проблема так и осталась за рамками понимания так-как это недоработка алгоритма считывать одно и тоже два раза в одной транзакции.
И ксатати для 3-го случая подойдет и Разделяемая блокировка.
Во-вторых 4-ый случай может быть хоть и редко, поэтому надо быть аккуратней при чтении итогов в одной таблице дважды в одной транзакции.    
Получается в 4-ом случае допустим отчет раделяемо блокирует всю таблицу регистра, а документ, который хочет записаться не может этого сделать так как Разделяемая блокировка и запись не совместимы. (Только вот интересно вывалится ошибка или будет ожидание в попытке произвести запись.)
В-третьих я так понял что объектный метод Записать накладывает Исключительную блокировку только в Автоматическом режиме.
В-четвертых, что объектные блокировки блокируют только интерактивно, и не гарантируют неприкосновенность данных вообще.
5. Просто шикарный материал, я думаю, что буду перечитывать его не один раз.

Получается что при построении ПриходнойНакладной где документ проводится в первые я просто заполняю движения, а там, где документ перепроводится
я в конце документа исключительно блокирую набор записей по этому регистратору и таблицу документов по ссылке на этот документ. (Разделяемая может обернуться взаимоблокировкой)
Так? Или можно ничего не накладывать? Что может произойти? - чисто теоретически? Какая-нибудь обработка программно изменит таблицу документа или набор записей? Это возможно?
Или какой-нибудь отчет будет считывать данные для анализа, а допустим мое проведение будет откатано назад и отчет будет оперировать измененными данными? (Хотя если отчет должен будет заблокировать таблицу разделяемо, то получит отказ и будет ожидать.)

Пипец. Грязное чтение и фантомные вставки не нужно побеждать. Это естественные процессы. Какая разница, будут ли отличаться результаты отчетов из-за того, что первый учел данные незавершенной транзакции, или второй увидел результаты транзакции не завершенной в момент формирования первого? С фантомными вставками таких расхождений будет меньше, потому как в нормальной системе откатов транзакций много меньше чем коммитов. Потерянные обновления платформа решит сама. Разработчику единственное, что нужно решать - обеспечить воспроизводимое чтение. И это не "читать два раза в одной транзакции". Это обусловленное проведение, когда формируемые движения зависят от информации в базе данных. Например расчет стоимости списания или расчет записей регистров расчета. И даже при обусловленном проведении нужно понимать, когда необходимо вмешиваться и дописывать блокировки к тем, что накладывает платформа, чтоб лишнего не наблокировать.

(9) Эти "свежие" требования от 2010 года. Блокировки на объект накладывать не надо, система сама прекрасно справляется с пессимистическими и оптимистическими блокировками объектов.
В рамках задач к сертификации управляемые блокировки нужно накладывать на регистры чтение из которых осуществляется при обусловленном проведении.