Здравствуйте!
Вопрос в теме.
Объясню что нужно конкретно.
Работаю сейчас с 1с 8.2 УТ(не типовая)SQL.
При работе пользователей выскакивает ошибка блокировки данных(Транзакция).
Одним из способов решения данной проблемы в 1с 7.7 (не типовой) было исключение из процедур "ПриЗаписи()" и "ОбработкаПроведения()" алгоритмов расчета данных, увеличивающих время запись в таблицы БД.
Собственно вот и возник вопрос "Когда начинается блокировка таблиц?" в 8.2.
На основании ответа пойму является ли лишним вычисления в процедурах "ПриЗаписи()", "ОбработкаПроведения"!
Прошу поделится информацией и мыслями по данной проблеме.
Спасибо за внимание!

(0) обращение к данным вызывает разделяемую блокировку

Если интересует запись - то в момент записи набора, записи документа или справочника и т.п. Но может накладываться и запросом или управляемой блокировкой. Практически и все . Но это начало блокировки - а вот конец - это завершением транзакции.

(0) ПередЗаписьюНаСервере() в модуле формы
Начало транзакции
ПередЗаписью() в модуле объекта
ПередЗаписью() в модуле объекта
ПриЗаписи() в модуле объекта
ОбработкаПроведения()
ПриЗаписиНаСервере() в модуле формы
Конец транзакции
ПослеЗаписиНаСервере() в модуле формы

Блокировка зависит от алгоритма работы.
Обычная перед "ПриЗаписи()"
Управляемая когда программист наложит.

В типовых мне говорили что при записи

(1) Пожалуйста конкретнее! Если можно пример.
Слово "разделяемую" моделирует несколько вариантов блокировок у меня в мыслях. Определения точного не могу пока найти.

А вообще в ут10 блокировки автоматические. Т.е. При записи блокируются таблицы полностью на уровне субд. Управляемые блокируют на уровне сервера, в ут11 например.

Тяжело понять детально какая таблица, когда блокируется когда нет знаний. Желаю их пополнить. Буду благодарен за  информация в виде ссылок или электронных книг и.т.д. по данному вопросу.

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

(6) есть два типа блокировок: разделяемая и исключительная.

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

Исключительная блокировка - если в данной транзакции необходимо изменить данные.

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

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

(9) спасибо за пояснение.
По пути прочитал данную тему.
http://1cexpo.ru/informacziya/27-blokirovki-dannyx-v-1spredpriyatii-8.html
Может еще кому пригодится!

(8) вот пример.

Есть две одновременно запущенные транзакции: A и Б. Обе транзации читают таблицу Т на предмет остатков, и если хватает количества, делают движение.

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

Обеим транзакциям хватает количество, и они начинают делать движение.

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

Так появляются взаимные блокировки.

Т.е если поставить в обработку проведеня документа обработчик ожидания на 10 мин тем самым заблокировав некоторые таблицы.
В этот момент другой пользователь попытается открыть журнал с этим документом или открыть сам документ получит сообщение по истечению времени ожидания блокировки о Ошибки транзакции где будит написано что такая то таблица заблокирована.
Я вас правильно понял?

(12) сомневаюсь, что для простого чтения журнала документов платформа использует какие либо механизмы поддержания целостности данных. Скорей всего, платформа читает данные как есть, посреди любой параллельно исполняемой транзакции. Абсолютно пофиг, какую версию данных увидит пользователь в журнале, старую или измененную.

(13) Скорей всего так и есть. Мне информации не хватает для вывода решения данной проблемы у людей.
Пример с чтение не удачный ну с записью параллельно документа думаю ошибка выскочит. И тут также сомневаюсь , полностью заблокирует таблицу транзакция или частично(нехватка знаний).
Не буду тыкать пальцем в небо! Ушел искать информацию. Постараюсь отписаться.
Спасибо за внимание!

(14) проставь "ДЛЯ ИЗМЕНЕНИЯ" во всех запросах к таблицам, в которые будешь писать.

(12) открывал журнал отчетов о розничных продажа и вот:
{Документ.ОтчетОРозничныхПродажах.Форма.ФормаСписка.Форма(51)}: Ошибка при получении значения атрибута контекста (Дата)
           Если Стр.ДанныеСтроки.Ссылка.Дата<='20120715235959' Тогда
по причине:
Конфликт блокировок при выполнении транзакции:
Microsoft OLE DB Provider for SQL Server: Превышено время ожидания запроса на блокировку.
HRESULT=80040E31, SQLSrvr: SQLSTATE=HYT00, state=33, Severity=10, native=1222, line=1

(16) потому что читать дату надо запросом

настройте http://www.gilev.ru/deadlock/ и http://www.gilev.ru/latch/ - бесплатные сервисы, которые специально для таких ситуаций созданы, настройте на свою базу
и они покажут причины блокировок,
я подскажу как исправить