|
Параллельные транзакции | ☑ | ||
---|---|---|---|---|
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) когда в голове каша - можно написать, что оппоненты сидят на веществах :)
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |