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

Код для проверки сделал такой:

&НаСервере
Процедура ЗаписьДокСервер ()
    НачатьТранзакцию();
    ДокументНовый = Документы.Документ1.СоздатьДокумент();
    ДокументНовый.Дата = ТекущаяДата();
    ДокументНовый.Записать();
    Sleep(СекундОжидания);
    ЗафиксироватьТранзакцию();
КонецПроцедуры

Подскажите, как обойти это ограничение?

>Подскажите, как обойти это ограничение?

перестать употреблять вещества

.... Управляемые блокировки возможно помогут.....

А зачем тут слип?

(3) имитация тормозов внутри транзакции))

у тебя все равно будет либо пессимистично все - ожидание записи и отлуп или оптимистично - неверная версия и отлуп

"Дальше выполняется некое время ожидания" - вы предупреждение что ли в обработку проведения засунули???

(3) - всё верно сказано - имитация долгого выполнения транзакции, так как в транзакции обрабатывается большой блок данных.
(6) - там выполняется WSscript на пинг, а в реальной базе большой блок данные. Среднее время отработки от начала транзакции до завершения - 7 минут.
(5) есть вариант делать записи параллельно? Или только не использовать транзакции?

(7) документ все равно пишется в транзакции неявной - ПередЗаписью/ПриЗаписи

(0) Никак.

а вообще это классика жанра - создание проблем административными средствами

(8) у меня не стоит вопрос записи одного документа - мне приходит пул информации, по которому нужно сделать около 200 документов. Всё это должно отрабатываться в режиме - "всё или ничего". Поэтому установлена транзакция в начале.

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

(11) вообще такие штуки принято делить на грязное/белое хранилище

в грязное засасывается все подряд, потом из него выгребают уже осознано адекватные записи и стругают сущности в базе

Видимо, нужно усложнять алгоритм, вводить какие-то вспомогательные объекты, двумя строчками Начать() и Зафиксировать() тут не обойтись...

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

Всем спасибо, проблему решил.
Все транзакции так отрабатывают на файловом варианте. Сейчас проверил на клиент-сервер с mssql - транзакции фиксирует отдельно друг от друга.
Буду переводить на сервер.
Всем добра :)

В регистр сведений клади, потом доки формируй.

>Все транзакции так отрабатывают на файловом варианте. Сейчас проверил на клиент-сервер с mssql - транзакции фиксирует отдельно друг от друга.

смешались в кучу люди кони

файловый лочит всю таблицу просто

а клиент сервер может залочить диапазоны по периоду (но может я не прав в упр. режиме) - тоже ничего туда не засунешь с той же датой

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

перечитал (0) - описывается ситуация одновременного изменения одной записи (что важно) таблицы 2мя транзакциями. Это нерешаемо в принципе.

((18) Ну, постгри, по моему, тоже всю таблицу лочит.
(20) Не, мил человек, ты не решил проблему, ты отсрочил синдромы. В будущем, когда объемы подрастут, ты к ней еще вернешься. Тут архитектуру нужно менять.

(20) большому кораблю - большая торпеда

(22) вот тут согласен, что возможно не вариант, и нужно будет урезать транзакции или использовать таблицу отложенной записи (из которой будет уже последовательно создаваться документы в основную таблицу).
Но на файловой блокируется вся таблица, а значит в принципе невозможна запись пока не отработает одна - нет возможно делать параллельные записи транзакций или увеличить пропускную способность.
Клиент-сервер даёт блокировку записи не блокируя таблицу, что даёт возможность повысить производительность записи параллельно.

(23) благодарю. Желаю вам и вашим родным не болеть.

(21) он не одну запись меняет... у него два клиента пытаются в базу свои записи запихать

>Клиент-сервер даёт блокировку записи не блокируя таблицу, что даёт возможность повысить производительность записи параллельно.

это пока он добрый

(25) ага а про эскалацию блокировок вы в курсе я надеюсь

(27) само собой что при достаточно высоком количестве таких попыток (более 7-8 наверное) будет уже откат транзакций по "превышен интервал ожидания". Сейчас всё пишется в один поток, и количество данных будет расти, и будет только накапливаться. Сейчас пытаюсь увеличить пропускную способность, притом что основные оптимизационные процедуры уже проведены (для уменьшения времени транзакции).

(28) надеюсь что не дойдёт до такого количества записей. Решился пока ограничиться 4-мя потоками, чтобы отследить изменения по производительности и не наращивать объёмы обработанных данных геометрически.

(30) вопрос не в количестве потоков а в количестве блокировок в одной транзакции на одной таблице

(31) в том числе - 200 документов это ограничение пакета обрабатываемых записей (в изначально поступаемом пакете). В одной транзакции сейчас записываю именно до 200 документов. И считаю что 20 тыс записей в одной транзакции совсем много, и действительно требуется пересмотреть архитектуру такой обработки.

При записи одна транзакция накладывает блокировку X на записываемые строки до конца транзакции, если вторая транзакция будет писать те же строки, то она просто будет ждать пока первая допишет. Это нормально, никакого таймаута в SQL сервер на этот счет вроде нет. Если записей много, более 5000, то произойдет эскалация блокировки X всю таблицу, но и тут особо страшного ничего нет. В этом случае просто будут ждать ВСЕ новые транзакции, независимо от того, пересекаются их записи с текущими или нет.

>Это нормально, никакого таймаута в SQL сервер на этот счет вроде нет.

в смысле? 20 сек - только на deadlock?

(34) Да, это только deadlock

(35) а в манах пишут что это просто timeout... подождал 20 сек и отвалился

(36) Да проверил, действительно 20 сек для всех, но на уровне сервера 1с, а не SQL сервера.

Но можно поменять в настройках базы Администрирование - Параметры информационной базы - Время ожидания блокировки данных

Deadlock мгновенен

(38) да, ни в одной другой теме у адинэсников нет такой каши в головах :-)

(39) Это сомнение в моих словах или согласие с ними?

(38), (39) Да, с дедлоком я немного тупанул, действительно если он уже случился то ждать дальше смысла нету, поэтому в параметрах системы настраивается именно время ожидания на блокировках

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

(42) И тут приходишь ты весь такой в белом.

>>Один пишет что починил одновременную запись одного и того же дока

Не надо передергивать, один док писаться одновременно не может, но если это делать, то СУБД сама выстроит транзакции в очередь за счет того, что одна из них немного подождет, если это ожидание не превысит 20 сек (по умолчанию заданных 1с)

(39) когда в голове каша - можно написать, что оппоненты сидят на веществах :)