Добрый день!
Собственно есть УТ 11 в которой загружаются и проводятся документы (Поступление товаров и услуг, Реализация товаров и услуг) с большим количеством строк в табличной части.

Подскажите пожалуйста кто знает возможно ли использовать "Многопоточная обработка данных" (https://infostart.ru/public/306865/) при проведении одного документа? Будет ли конфликт блокировки при записи в регистр?
---
Не получится. Потому что регистр накопления подчинен регистратору. Один регистратор = один набор записей. Если вы будете пытаться писать, например, набор записей в 8 потоков, то они будут друг друга перетирать, и в реальности останется только набор, состоящий из результатов последнего потока.

Как вариант - отказаться от объектной модели, и писать напрямик в SQL, нарушая лицензионное соглашение.
---
Очень много это сколько? Конфликт блокировок может возникнуть если возникнет эскалация блокировок. Возникнет она если записей будет больше 100 000.
---
больше 100 000 строк
---
в таб. частях максимум 99 999 строк можно записать. А количество записей в наборе записей ограничено оперативной памятью. Такое точно, нужно разбивать на несколько документов(регистраторов). Если вам потребуется перезаполнить одну строку, то придется заново перезаписывать все.
---
Не получится. Потому что регистр накопления подчинен регистратору. Один регистратор = один набор записей. Если вы будете пытаться писать, например, набор записей в 8 потоков, то они будут друг друга перетирать, и в реальности останется только набор, состоящий из результатов последнего потока.

Как вариант - отказаться от объектной модели, и писать напрямик в SQL, нарушая лицензионное соглашение.
---
.....либо наборы записей запишутся последовательно.....
---
Кроме прямой записи в SQL есть какие-нибудь решения для оптимизации задачи, уменьшение времени проведения документа?
---
Отложенное проведение
---
создавать несколько документов, скажем по 10000 строк в ТЧ + как уже предложили, отложенное проведение.
---
да тоже об этом подумал, спасибо! а запускать проведение документа тогда нужно в многопоточном режиме? или можно разом проводить?
---
в теории можно загружать данные не в один документ (с 100 000 строк), а скажем в 10 документов (по 10 000 строк) и запускать в многопоточном режиме?
---
можно и в многопоточном, если можно разделить на потоки, т.е. существуют разные комбинации измерений регистра.
---
Ну наконец-то настало время, когда каждый китаец написал свою статью про многопоточность, но не каждый китаец знает, как ее использовать )))

Можно сделать запись в регистр многопоточно, но не совсем. Но суть для именно проведения документа такая:
1. Собирается пул данных и делится на порции.
2. Каждая порция скармливается отдельному потоку (как вариант - общее количество данных деленное на количество ядер., которые не жалко задействовать в операции).
3. Все.
4. В потоке создается набор записей регистра/регистров, устанавливается отбор по регистратору, производится формирование набора из переданных для обработки данных и данные записываются с признаком Замещать = ЛОЖЬ
.5. Совсем все.
---
так это понятно), был вопрос про то, что записать в регистр накопления данные из одного регистратора, в многопоточном режиме
---
а я о чем?
---
О сути проведения документов в многопоточном режиме.
Если в многопоточном режиме запустить одни документ в большим объемом строк, и разделить на потоки, то к примеру 1 поток заблокирует регист и 2 поток не сможет записать данные пока 1 поток не освободит регист. Итого получится последовательная запись в регистр.
Правильно?
---
неа.

Документ проводится, регистр не пишется - он пишется в отдельных фоновых заданиях в виде дописываемого (незамещающего) набора записей. Документ не обязан дожидаться, пока фоновые задания запишут регистры, поэтому тут запимь в обзем-то без транзакции происходит, т.к. мы просто сохраняем набор записей с отбором по регистратору в нескольких фоновых заданиях. У меня так в тестах достигался пропорциональный рост производительности.
---
.....в какой-то момент найдется пользователь, который решит интерактивно перепровести/записать документ со 100500 строками в тч и тем самым "положит" базу на неопределенное время :)
---
тем самым "положит" базу на неопределенное времяНу это проблема 1С, хотя 100500 строк - это очень немного в действительности. Если на сервере достаточно ядер, то все будет работать как и раньше (если, конечно, база не файловая).
---
в виде дописываемого (незамещающего) набора записей
Это как? не совсем понятно мне(
---
он пишется в отдельных фоновых заданиях
А в случае если нужны, допустим остатки сразу после проведения? тогда эта схема не сработает же?
---
А в случае если нужны, допустим остатки сразу после проведения?Остатки чего? Не так часто в разных строках документа встречаются одни и те же разрезы в части остатков. С другой стороны, общее время проведения снижается, снижается и время для доступности остатков, а контроль остатков можно сделать в момент генерации выборки для формирования движений, и если текущих остатков недостаточно - отменять проведение по стандартной схеме.