|
Одновременное создание двух документов | ☑ | ||
---|---|---|---|---|
0
luter-89
27.02.17
✎
15:35
|
Кто подскажет как происходит одновременное создание двух документов на уровне СУБД MS SQL. Могут ли быть блокировки если эти документы полностью различны кроме даты и номера. ПО идее при одновременном создании должен быть один номер, одна дата и одна и та же ссылка у записей в БД
|
|||
1
ELEA26
27.02.17
✎
15:39
|
(0)Как не прыгай - они не одновременно создаются в БД.
|
|||
2
luter-89
27.02.17
✎
15:40
|
Читал на форумах, где Радченко писал, что создаются одновременно
|
|||
3
1Снеговик
гуру
27.02.17
✎
15:42
|
(0) проблема то в чем?
|
|||
4
Кирпич
27.02.17
✎
15:43
|
(2) в компьютерах нужно очень постараться чтобы что нибудь случилось одновременно
|
|||
5
Fragster
гуру
27.02.17
✎
15:44
|
>ПО идее при одновременном создании должен быть один номер, одна дата и одна и та же ссылка у записей в БД
по твоей идее? |
|||
6
Fragster
гуру
27.02.17
✎
15:45
|
хватит употреблять
|
|||
7
Господин ПЖ
27.02.17
✎
15:46
|
тип отведенный под дату позволяет запихнуть в одну секунду больше одного документа
|
|||
8
Господин ПЖ
27.02.17
✎
15:46
|
и пока один записывается второй ждет - блокировки работают
|
|||
9
luter-89
27.02.17
✎
15:46
|
Есть REST клиент, который создает в 1С заказы, REST запросы могут выполняться параллельно. Случилась ситуация, когда REST клиент отправил два одинаковых запроса на создание заказа. По сути в 1С должны параллельно создаться два одинаковых заказа. В процессе создания заказа есть проверка по определенному ID, чтобы не было дублей. Получилось так, что создались два одинаковых заказа с одинаковым ID. Если бы один заказ создался бы раньше другого, то проверка бы выдала, что по такому ID уже есть заказ и второй не создался бы.
|
|||
10
Dmitrii
гуру
27.02.17
✎
15:47
|
(0) Что в твоём понимании значит "при одновременном"?
Генерацию уникальных номеров и кодов объектов обеспечивает сервис нумерации кластера серверов 1С. Этот сервис един для одной информационной базы. И даже пр переносе (миграции) сервиса между рабочими серверами кластера потери данных не происходит. То есть сервис продолжает обеспечивать уникальность кодов и номеров создаваемых объектов. |
|||
11
ELEA26
27.02.17
✎
15:48
|
(2) фигню написал. SQL никак 2 одновременно записи в таблицу не напишет. Так что нет. Одновременно не создаются документы.
|
|||
12
Господин ПЖ
27.02.17
✎
15:50
|
(9) это норма. первый спросил есть документ? и второй спросил есть ли документ. его не было, дальше создаются дубли
|
|||
13
Dmitrii
гуру
27.02.17
✎
15:51
|
(9) >> ...есть проверка по определенному ID, чтобы не было дублей
>> ...создались два одинаковых заказа с одинаковым ID Обратитесь к *опоруким программистам - авторам алгоритма проверки. Уточните у них по какой причине не были наложены исключительные блокировки по этому полю до начала проверки и вплоть до завершения транзакции записи объекта в БД. |
|||
14
luter-89
27.02.17
✎
15:51
|
(12) Так если в SQL не происходит одновременного создания записей, то документ должен был быть в БД
|
|||
15
Это_mike
27.02.17
✎
15:51
|
ну не слышал он о блокировках...
|
|||
16
ELEA26
27.02.17
✎
15:52
|
(9) Это совсем другая тема. Создался и записался - разное. И на уровне SQL одно, на уровне 1С - другое. Когда 1С создает документ, то SQL пока еще ничего не делает, сервер 1С выдает номер только (но не SQL). А вот при записи да. Притом вопрос проводится документ или нет. Если проводится и во время проведения проверяется это ID, то да, странно т.к. там все транзакции все. А если только запись - то смотря как и что написано. Но как вопрос в теме - нет, одновременно SQL не создает 2 документа. Более того, на 1 то документ SQL делает далеко не 1 запись.
|
|||
17
Это_mike
27.02.17
✎
15:52
|
(13)картина репина "*опоголовый обращается к *опоруким"
|
|||
18
luter-89
27.02.17
✎
15:53
|
(13) А причем тут исключительные блокировки? Документов еще нет в базе
|
|||
19
Господин ПЖ
27.02.17
✎
15:54
|
(18) затем... откройте мурзилку по совместимости уровней блокировок
|
|||
20
ELEA26
27.02.17
✎
15:55
|
(14) Запись в 1С и запись в SQL - это ваще разное.
|
|||
21
Господин ПЖ
27.02.17
✎
15:56
|
(14) для этого запрос на поиск и создание надо завернуть в одну транзакцию
чтобы второй ждал |
|||
22
luter-89
27.02.17
✎
15:57
|
(21) Алгоритм HTTP сервиса парсинга REST запроса, поиска заказа по ID, создание нового происходит в транзакции
|
|||
23
ELEA26
27.02.17
✎
15:58
|
(22) Ну а поиск тоже в транзакции?
|
|||
24
Garykom
гуру
27.02.17
✎
15:59
|
(22) Вся очередь обработки запросов рест в одной транзакции, а не параллельная обработка разных запросов где каждый в своей транзакции
|
|||
25
luter-89
27.02.17
✎
16:00
|
Оказывается транзакции нет, только что посмотрел
|
|||
26
Garykom
гуру
27.02.17
✎
16:00
|
(24)+ Ну или делай резервирование номерков если параллельно хочешь
|
|||
27
Это_mike
27.02.17
✎
16:14
|
(26) зачем? достаточно транзакционно номер запрашивать. правда, возможно дырки будуит
|
|||
28
Вафель
27.02.17
✎
16:27
|
если без блокировок, то 2 транзакция не увидит 1 ибо только read_commited.
Это если у тебя ID - это просто реквизит |
|||
29
Вафель
27.02.17
✎
16:28
|
(25) транзакция при записи всегда есть
|
|||
30
Fragster
гуру
27.02.17
✎
16:31
|
а кто-нибудь смотрел, как это работает? https://i.imgur.com/ikWtyMi.png что-то в мануалах не нашел....
|
|||
31
Fragster
гуру
27.02.17
✎
16:32
|
в смысле из справки ничего не понятно, когда это работает?
|
|||
32
Вафель
27.02.17
✎
16:32
|
(30) Это с какого релиза?
|
|||
33
Fragster
гуру
27.02.17
✎
16:32
|
я хз, 8.3.6 есть
|
|||
34
luter-89
27.02.17
✎
16:34
|
Так как все - таки решить проблему то?
|
|||
35
luter-89
27.02.17
✎
16:34
|
Обернуть все в транзакцию?
|
|||
36
Господин ПЖ
27.02.17
✎
16:34
|
>если без блокировок, то 2 транзакция не увидит 1 ибо только read_commited.
в зависимости от 1с и базы может быть вообще read_commited_snapshot - вообще блокировок на чтение не будет |
|||
37
luter-89
27.02.17
✎
16:36
|
(36) Мы используем read_commited_snapshot
|
|||
38
Вафель
27.02.17
✎
16:36
|
(36) блокировок нет, но и не увидит
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |