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

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

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

Подскажите, как обойти это ограничение?
1 Господин ПЖ
 
24.07.15
16:10
>Подскажите, как обойти это ограничение?

перестать употреблять вещества
2 Heckfy
 
24.07.15
16:10
.... Управляемые блокировки возможно помогут.....
3 xaozai
 
24.07.15
16:11
А зачем тут слип?
4 VikingKosmo
 
24.07.15
16:11
(3) имитация тормозов внутри транзакции))
5 Господин ПЖ
 
24.07.15
16:11
у тебя все равно будет либо пессимистично все - ожидание записи и отлуп или оптимистично - неверная версия и отлуп
6 Heckfy
 
24.07.15
16:12
"Дальше выполняется некое время ожидания" - вы предупреждение что ли в обработку проведения засунули???
7 Strimteam
 
24.07.15
16:16
(3) - всё верно сказано - имитация долгого выполнения транзакции, так как в транзакции обрабатывается большой блок данных.
(6) - там выполняется WSscript на пинг, а в реальной базе большой блок данные. Среднее время отработки от начала транзакции до завершения - 7 минут.
(5) есть вариант делать записи параллельно? Или только не использовать транзакции?
8 Господин ПЖ
 
24.07.15
16:17
(7) документ все равно пишется в транзакции неявной - ПередЗаписью/ПриЗаписи
9 H A D G E H O G s
 
24.07.15
16:17
(0) Никак.
10 Господин ПЖ
 
24.07.15
16:18
а вообще это классика жанра - создание проблем административными средствами
11 Strimteam
 
24.07.15
16:19
(8) у меня не стоит вопрос записи одного документа - мне приходит пул информации, по которому нужно сделать около 200 документов. Всё это должно отрабатываться в режиме - "всё или ничего". Поэтому установлена транзакция в начале.
12 бомболюк
 
24.07.15
16:20
это противоречит основным принципам транзакций, в частности, принципу изолированности.
13 Господин ПЖ
 
24.07.15
16:22
(11) вообще такие штуки принято делить на грязное/белое хранилище

в грязное засасывается все подряд, потом из него выгребают уже осознано адекватные записи и стругают сущности в базе
14 xaozai
 
24.07.15
16:22
Видимо, нужно усложнять алгоритм, вводить какие-то вспомогательные объекты, двумя строчками Начать() и Зафиксировать() тут не обойтись...
15 Господин ПЖ
 
24.07.15
16:25
(14) да там все равно может ж.па настигнуть в любой момент... "кривая" попытка/исключения внутри этих скобок - и все - в данной транзакции уже были ошибки.
16 Strimteam
 
24.07.15
16:26
Всем спасибо, проблему решил.
Все транзакции так отрабатывают на файловом варианте. Сейчас проверил на клиент-сервер с mssql - транзакции фиксирует отдельно друг от друга.
Буду переводить на сервер.
Всем добра :)
17 rs_trade
 
24.07.15
16:27
В регистр сведений клади, потом доки формируй.
18 Господин ПЖ
 
24.07.15
16:31
>Все транзакции так отрабатывают на файловом варианте. Сейчас проверил на клиент-сервер с mssql - транзакции фиксирует отдельно друг от друга.

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

файловый лочит всю таблицу просто
19 Господин ПЖ
 
24.07.15
16:32
а клиент сервер может залочить диапазоны по периоду (но может я не прав в упр. режиме) - тоже ничего туда не засунешь с той же датой
20 Strimteam
 
24.07.15
16:35
(18) - я спрашивал про возможность параллельной записи в одну таблицу двух транзакций, вернее при незавершённой первой зафиксирование второй. Ваш "конструктив" в сообщениях (не всех) не беру в расчёт.
Спросил решения проблемы - решил. Поэтому вам спасибо что рассказали как. Надеюсь так же помог чем-нибудь и вам :)
21 бомболюк
 
24.07.15
16:39
перечитал (0) - описывается ситуация одновременного изменения одной записи (что важно) таблицы 2мя транзакциями. Это нерешаемо в принципе.
22 Heckfy
 
24.07.15
16:40
((18) Ну, постгри, по моему, тоже всю таблицу лочит.
(20) Не, мил человек, ты не решил проблему, ты отсрочил синдромы. В будущем, когда объемы подрастут, ты к ней еще вернешься. Тут архитектуру нужно менять.
23 Господин ПЖ
 
24.07.15
16:42
(20) большому кораблю - большая торпеда
24 Strimteam
 
24.07.15
16:44
(22) вот тут согласен, что возможно не вариант, и нужно будет урезать транзакции или использовать таблицу отложенной записи (из которой будет уже последовательно создаваться документы в основную таблицу).
Но на файловой блокируется вся таблица, а значит в принципе невозможна запись пока не отработает одна - нет возможно делать параллельные записи транзакций или увеличить пропускную способность.
Клиент-сервер даёт блокировку записи не блокируя таблицу, что даёт возможность повысить производительность записи параллельно.
25 Strimteam
 
24.07.15
16:44
(23) благодарю. Желаю вам и вашим родным не болеть.
26 Господин ПЖ
 
24.07.15
16:46
(21) он не одну запись меняет... у него два клиента пытаются в базу свои записи запихать
27 Господин ПЖ
 
24.07.15
16:46
>Клиент-сервер даёт блокировку записи не блокируя таблицу, что даёт возможность повысить производительность записи параллельно.

это пока он добрый
28 gigi789
 
24.07.15
16:48
(25) ага а про эскалацию блокировок вы в курсе я надеюсь
29 Strimteam
 
24.07.15
16:49
(27) само собой что при достаточно высоком количестве таких попыток (более 7-8 наверное) будет уже откат транзакций по "превышен интервал ожидания". Сейчас всё пишется в один поток, и количество данных будет расти, и будет только накапливаться. Сейчас пытаюсь увеличить пропускную способность, притом что основные оптимизационные процедуры уже проведены (для уменьшения времени транзакции).
30 Strimteam
 
24.07.15
16:51
(28) надеюсь что не дойдёт до такого количества записей. Решился пока ограничиться 4-мя потоками, чтобы отследить изменения по производительности и не наращивать объёмы обработанных данных геометрически.
31 gigi789
 
24.07.15
16:53
(30) вопрос не в количестве потоков а в количестве блокировок в одной транзакции на одной таблице
32 Strimteam
 
24.07.15
16:56
(31) в том числе - 200 документов это ограничение пакета обрабатываемых записей (в изначально поступаемом пакете). В одной транзакции сейчас записываю именно до 200 документов. И считаю что 20 тыс записей в одной транзакции совсем много, и действительно требуется пересмотреть архитектуру такой обработки.
33 Art igloo
 
24.07.15
17:10
При записи одна транзакция накладывает блокировку X на записываемые строки до конца транзакции, если вторая транзакция будет писать те же строки, то она просто будет ждать пока первая допишет. Это нормально, никакого таймаута в SQL сервер на этот счет вроде нет. Если записей много, более 5000, то произойдет эскалация блокировки X всю таблицу, но и тут особо страшного ничего нет. В этом случае просто будут ждать ВСЕ новые транзакции, независимо от того, пересекаются их записи с текущими или нет.
34 Господин ПЖ
 
24.07.15
17:13
>Это нормально, никакого таймаута в SQL сервер на этот счет вроде нет.

в смысле? 20 сек - только на deadlock?
35 Art igloo
 
24.07.15
17:14
(34) Да, это только deadlock
36 Господин ПЖ
 
24.07.15
17:32
(35) а в манах пишут что это просто timeout... подождал 20 сек и отвалился
37 Art igloo
 
24.07.15
18:09
(36) Да проверил, действительно 20 сек для всех, но на уровне сервера 1с, а не SQL сервера.

Но можно поменять в настройках базы Администрирование - Параметры информационной базы - Время ожидания блокировки данных
38 H A D G E H O G s
 
24.07.15
21:31
Deadlock мгновенен
39 floody
 
24.07.15
21:59
(38) да, ни в одной другой теме у адинэсников нет такой каши в головах :-)
40 H A D G E H O G s
 
24.07.15
23:36
(39) Это сомнение в моих словах или согласие с ними?
41 Art igloo
 
25.07.15
07:39
(38), (39) Да, с дедлоком я немного тупанул, действительно если он уже случился то ждать дальше смысла нету, поэтому в параметрах системы настраивается именно время ожидания на блокировках
42 1sanekmaloi1
 
25.07.15
10:10
Один пишет что починил одновременную запись одного и того же дока,другой пишет что таймаутов не существует, а дедлок длится 20 сек. Остановите тут, я сойду, хоть почитали бы книги какие чтоли.
43 Art igloo
 
25.07.15
12:10
(42) И тут приходишь ты весь такой в белом.

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

Не надо передергивать, один док писаться одновременно не может, но если это делать, то СУБД сама выстроит транзакции в очередь за счет того, что одна из них немного подождет, если это ожидание не превысит 20 сек (по умолчанию заданных 1с)
44 kofeinik
 
25.07.15
13:42
(39) когда в голове каша - можно написать, что оппоненты сидят на веществах :)
Выдавать глобальные идеи — это удовольствие; искать сволочные маленькие ошибки — вот настоящая работа. Фредерик Брукс-младший