Таблица 1sjourn ошибка обращения к данным при транзакции выполняемой другим пользователем

FEAS

09.04.10 — 09:12

povar

1 — 09.04.10 — 09:13

базу переписывать

Ёпрст

2 — 09.04.10 — 09:14

ставить всем 0.

Дядя Васька

3 — 09.04.10 — 09:15

supremum

4 — 09.04.10 — 09:17

Или распределить работу кадровиков, расчетчиков так, что бы не возникала обходимость одновременного обращения к одним и тем же таблицам.

FEAS

5 — 09.04.10 — 09:18

Если в запросе условие по подразделению он ведь блокирует толко эти записи или нет?

ДенисЧ

6 — 09.04.10 — 09:19

(5) Нет.

Ёпрст

7 — 09.04.10 — 09:20

(5) запрос вообще ничего не блокирует.

DrZombi

8 — 09.04.10 — 09:20

Ёпрст

9 — 09.04.10 — 09:21

+7 блокировка, только ежели кто-то чего-то проводит, ибо проведение — это всегда транзакция.

DrZombi

10 — 09.04.10 — 09:21

(7)Может быть, но ты записать, то же нечего не смогешь
Только читать

Ёпрст

11 — 09.04.10 — 09:21

(8) Гон.
1с-кий запрос построен на «грязном чтении» и он не блокирует ничего.

Ёпрст

12 — 09.04.10 — 09:22

(10) да ну ?

FEAS

13 — 09.04.10 — 09:23

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

FEAS

14 — 09.04.10 — 09:24

При формировании отчетов

FEAS

15 — 09.04.10 — 09:25

выборка блокирует как я понимаю?

ДенисЧ

16 — 09.04.10 — 09:26

1dvd

17 — 09.04.10 — 09:26

(15) Твоя задача, чтобы проведение и запись шли быстрее

DrZombi

18 — 09.04.10 — 09:28

(11)Ну не гони, у нас как раз вот запросы от 1С и блокировали всю базу, при этом это просто отчет по регистру
При этом, пока не выкидывали сего пользователя, все курили

FEAS

19 — 09.04.10 — 09:30

а как тогда? одна делает расчет другая формирует отчет и ошибка но записей пока нет если перебор не влияет то что?

ДенисЧ

20 — 09.04.10 — 09:31

(19) Вот как разсчёт и блокирует…

FEAS

21 — 09.04.10 — 09:31

весь журнал расчетов?

Ёпрст

22 — 09.04.10 — 09:33

(18) ты бред то не неси..

FEAS

23 — 09.04.10 — 09:33

нет смысла ставить секунды да хоть 500? просто расчет мин 20 идет

Дядя Васька

24 — 09.04.10 — 09:33

(22) Руками в тот отчет транзакцию влепили, вот и блокировал походу.

FEAS

25 — 09.04.10 — 09:34

тогда на 20 мин все записи заблокированы транзакцией? Отчет не может?

Дядя Васька

26 — 09.04.10 — 09:35

(25) Ну не так чтобы все, но общий журнал блокирует, а без него все висит…

FEAS

27 — 09.04.10 — 09:37

в отчете нет ранзакций

FEAS

28 — 09.04.10 — 09:37

как тчеты формировать тогда что не правильно

FEAS

29 — 09.04.10 — 09:37

какой общий?

Ёпрст

30 — 09.04.10 — 09:38

Еще раз — ошибка блокировки возникает только при записи/проведении объектов ИБ..
и всё.

FEAS

31 — 09.04.10 — 09:39

Ну я понял это у расчетчика которая хочет сформировать отчет вылазит данная ошибка

Ёпрст

32 — 09.04.10 — 09:39

(31) ты это понял или ты это видел ?

FEAS

33 — 09.04.10 — 09:40

вот видел

DrZombi

34 — 09.04.10 — 09:40

(22)Сам был поражен, но запрос был по дебиторке и брал данные за год

Ёпрст

35 — 09.04.10 — 09:42

(34) да хоть за 100..

Ёпрст

36 — 09.04.10 — 09:42

(33) чего видел ? Ленина ?..

FEAS

37 — 09.04.10 — 09:43

вобщем если один человек формирует отчет, а у другого проводится расчет то у которого отчет вылазит ошибка блокировки данных другим пользователем

Ёпрст

38 — 09.04.10 — 09:44

(37) не верю.
Что за конфа ? Что за отчет ?

DrZombi

39 — 09.04.10 — 09:45

DrZombi

40 — 09.04.10 — 09:46

(38)Я ему верю И еще как
(0)Совет, пиши прямые запросы

Ёпрст

41 — 09.04.10 — 09:47

сказочники.

Дядя Васька

42 — 09.04.10 — 09:49

(29) 1sjourn вестимо. Как правило одинэсовские запросы его джойнят, а во время проведения он заблокирован полностью, вот и обломинго с отчетом.

FEAS

43 — 09.04.10 — 09:51

ага на него ругается на 1sjourn правильно понял

FEAS

44 — 09.04.10 — 09:51

и как быть?

povar

45 — 09.04.10 — 09:53

(44) я ж тебе сразу сказал, базу надо переписывать

DrZombi

46 — 09.04.10 — 09:53

(44)Убрать запросы из модуля проведения
Оптимизировать сам метод проведения, постараться не писать в другие справочники, во время проведения…
Пользователям стараться вдалбливать, что не кашерно делать один документ с 20000 строк Лучше 20000 документов, но с одной строкой

Ёпрст

47 — 09.04.10 — 09:57

FEAS

48 — 09.04.10 — 10:01

Обработка расчет зарпалты, она там блокирует

FEAS

49 — 09.04.10 — 10:01

когда считаем зарплату

FEAS

50 — 09.04.10 — 10:02

Там используются транзакции

FEAS

51 — 09.04.10 — 10:02

не документ

Ёпрст

52 — 09.04.10 — 10:03

(48) п..ц.
Ты разницу между отчетом — это чтение данных и Обработкой расчет зарпалты — которая вносит изменения в саму ИБ не видишь???

FEAS

53 — 09.04.10 — 10:04

как не вижу я понимаю

FEAS

54 — 09.04.10 — 10:04

там транзакции используются

Skom

55 — 09.04.10 — 10:05

Ёпрст

56 — 09.04.10 — 10:06

(54) тем более, журнал и другие таблички уже заблокированы другим пользователем — пока он не проведёт свой документ — ты транзакцию не сможешь поставить — идёт ожидание захвата таблички.
И всего лишь.

FEAS

57 — 09.04.10 — 10:07

Если так? тогда зачемошибка если просто чтение

FEAS

58 — 09.04.10 — 10:07

убрать транзакции?

FEAS

59 — 09.04.10 — 10:08

доки ни кто  вэто время может не проводит

FEAS

60 — 09.04.10 — 10:08

только расчет, и отчеты

Нафигатор

61 — 09.04.10 — 10:08

(0) На каких именно строчках модулей ошибки возникают?

FEAS

62 — 09.04.10 — 10:10

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

povar

63 — 09.04.10 — 10:14

(48) бу га га

povar

64 — 09.04.10 — 10:14

это далеко не отчет

Ёпрст

65 — 09.04.10 — 10:14

(57) Не тупи — сам же сказал — что в обработке твоей транзакция +, на сколько я помню Зик — эта обработка делает запись в ИБ..

FEAS

66 — 09.04.10 — 10:21

да транзакция в обработке она вносит записи в журнал расчетов считает. В этоже время другой человек печатает отчеты

FEAS

67 — 09.04.10 — 10:23

уберу транзакцию

FEAS

68 — 09.04.10 — 10:23

и нафиг

FEAS

69 — 09.04.10 — 10:25

не туплю а по твоему размышлению у человека который формирует отчеты не должно быть ошибки

Дядя Васька

70 — 09.04.10 — 10:25

(67) Чревато… Тогда смогут двое одновременно в эту табличку писать, результат может получиться несколько неожиданным )

DrZombi

71 — 09.04.10 — 10:29

Ёпрст

72 — 09.04.10 — 10:31

(71) Не тупи.. у нас юзверов до 80 в базе — таких проблем нет и не было никогда.

DrZombi

73 — 09.04.10 — 10:32

(72)Ну я же пишу… не оптимизируй запросы, на прямые и период возьми по само использованному регистру за год, а не за 10 дней , как макс

Ёпрст

74 — 09.04.10 — 10:32

+71 Если ты такой неверующий Фома- смотри профайлер в скуле, например, там везде хинт nolock в запросе..
Табличка никогда не блокируется, хоть за пятилетку строй запросы свои.

DrZombi

75 — 09.04.10 — 10:32

+(72)И повиснит твоя база… не забудь отрубить ВК

Ёпрст

76 — 09.04.10 — 10:33

(75) Хорош чушь пороть, не позорился бы..

DrZombi

77 — 09.04.10 — 10:33

(74)Но и записать ты при этом не смогешь, 1С требует при записи в табличку (7.7) монопольного доступа, т.е. лочит всю таблицу

DrZombi

78 — 09.04.10 — 10:34

(76)Вот я то же бы утверждал, что код в (39) не реален… но он так себя и ведет

Ёпрст

79 — 09.04.10 — 10:34

(77) С какой радости то???
Еще раз — ЗАПРОС в 1с не лочит НИЧЕГО.

DrZombi

80 — 09.04.10 — 10:35

(79)Тоже сам все еще поражаюсь
Сам многому удивляюсь в 7.7, за все годы работы

Invalid

81 — 09.04.10 — 10:35

DrZombi

82 — 09.04.10 — 10:36

(79)Я тоже поразился, что он при 1С-ных запросах ложет туже самую таблицу, но во временные файлы

Ёпрст

83 — 09.04.10 — 10:36

Ты там не отмазывайся…сказочник.

DrZombi

84 — 09.04.10 — 10:38

(83)Если бы… я тебе пишу, что и палка стреляет
И твои утверждения, что нечему лочиться там тоже ошибочные Не ты же писать платформу 7.7

Ёпрст

85 — 09.04.10 — 10:40

(84) оставайся дальше в своих грёзах.. только вот тут не надо этого писать..

FEAS

86 — 09.04.10 — 10:49

в это время никто другой не делает это , если запрос чисто читает то он должен без ошибки читать и все

FEAS

87 — 09.04.10 — 10:51

При транзакции запрос не может счиать или нет  Ёпрст3?

DrZombi

88 — 09.04.10 — 10:55

(87)Видишь ли (85) все время твердить, что нет этого у тебя, т.е. реально ты пишешь фигню и нечего не «лочится»
А я вообще сказочник, мне это привиделось
…Ты начни думать своей головой, у нас другие ошибки и баги в 7.7… Ты многие найдешь и в 8-ке И так же повстречаешь новые, для тебя, 7.7

МуМу

89 — 09.04.10 — 10:58

МуМу

90 — 09.04.10 — 11:02

То 88. Я редко верю тому что говорят пользователи. Поставь систему мониторинга либо проведи эксперимент и убедись в обратном.   Я уверен что если у FEAS спросить а проводил ли он лично одновременно документ(запрос в цикле на х итераций в отчете и предупреждение в конце проведения документа) и отчет и видел ли блокировку? —  скажет скорее всего нет. А ведь это несложно сделать.

МуМу

91 — 09.04.10 — 11:04

Единственное но — не нужно путать отчеты и обработки. Обработка выполняя в транзакции определенные действия на изменения действительно может вступать в блокировку.

DrZombi

92 — 09.04.10 — 11:05

(89)Я практик… мне твое написано… мало что говорит…. как правил у нас Аналитик, так красиво расписал программу, щас смотрю на ее реализацию, в 7.7.
Думаю, он много с экономил на программистах, код писали школьники, ужо не говоря про студентов с бух. факов

FEAS

93 — 09.04.10 — 11:07

когда отчеты формируются ошибка вылазит за чем что то проверять, сам вижу, в это время работает обработка на запись в ИБ. Документы мне пока не нужны

DrZombi

94 — 09.04.10 — 11:07

+(89)Не поленись… проведи експеремент на 10 различных ПК и на данных годовой давности и тогда и пиши, то что написал программер, что бы от него отвалили

FEAS

95 — 09.04.10 — 11:11

Если гвоитте отчеты не блокируют тогда зачем ошибка то не пойму, если они только на чтение.

МуМу

96 — 09.04.10 — 11:12

То FEAS. Ну тогда приведи точно название ошибки, название отчета и название обработки. Бывает исключение из правил (менее 1 процента) но я очень сомневаюсь что это тот случай.

FEAS

97 — 09.04.10 — 11:15

DrZombi

98 — 09.04.10 — 11:21

(97)Где то была библиотечка, которая в дбф-е снимала нагрузку на базу при транзакции
Но не помню как называлось, вроде ромикса
Тебе она нуна

sapphire

99 — 09.04.10 — 11:26

(89) Это смотря как написать отчет.

nop

100 — 09.04.10 — 11:26

100

Как-то на форуме прочитал сообщение типа» а вот знакомый админ удалил Tablockx и поставил rowlock в хранимых процедурах и все закрутилось, завертелось»… Эта мысль, по-моему, достаточно показательна для многих из 1С-программистов и особенно для новичков.

Для того, чтобы не наломать дров в вашей ИТ системе, необходимо : во-первых, понимать, для чего существуют блокировки в МS SQL Server , во-вторых, понимать, как устроен блокировочный механизм в 1С 7.7 и MS SQL.

По первой части есть масса литературы, и поэтому не хотелось бы ее пересказывать…Отмечу лишь принципиальные моменты…

В MS SQL есть понятие блокировок и подсказок блокировок. Основное предназначение — избежать проблем некорректного(грязное чтение, чтение фантомов и т.п.) чтения информации.

Для 1С 7.7 значимы следующие виды блокировок

Holdlock – Захватывает разделяемую блокировку до завершения транзакции.

Nolock — Применима только к оператору select . Читает все…

Tablock — Используется блокировка на уровне таблиц.

Tablockx — Используется монопольная блокировка таблицы.

Отдельно выделю подсказки блокировки, которые «горячие» головы рекомендуют применять

Rowlock — блокировка на уровне строк

Updlock — блокировка на изменение

Readpast — Применима только для Select . Пропускаются строки блокированные( rowlock ) другими транзакциями.

Для того чтобы понять, как действуют эти блокировки, необходимо почитать соответствующую литературу, а еще лучше самим проверить на практике эти блокировки в различных ситуациях…

На специфике реализации блокировок в 1С 7.7 остановлюсь подробнее.

Механизм блокировок в 1С 7.7 максимально простой — блокируется все и по максимуму.

Интересней всего, конечно, реализация блокировок на документы т.к. как правило это и является самым узким местом системы, а также документы и являются источником конфликтов.

Начнем с того, что в 1С 7.7 существует специальная таблица _1 sjourn, где хранятся внутренние идентификаторы всех документов. При записи, проведении и т.п. операциях с документами 1С накладывает блокировку на таблицу _1 sjourn и соответственно в системе в один момент времени может проводиться не более одного документа. То есть _1 sjourn выступает в роли своеобразного семафора. До тех пор, пока не завершиться транзакция и соответственно не будет снята блокировка с таблицы, все остальные клиенты будут ждать разблокировки и, самое интересное, как это они будут делать. В момент ожидания 1С 7.7 загружает ресурсы сервера, т.к. непрерывно сканирует таблицу на вопрос разблокировки и поэтому загружает процессор по максимуму.

Удалить механизм блокировок можно путем изменения хранимых процедур, через которые 1С 7.7 проверяют таблицы на блокировки. А точнее, удалить хинты на блокировку таблиц.

Например, в хранимой процедуре _1 sp __1 SJOURN _ TLockX в конструкции select @i=1 from _1SJOURN(TABLOCKX HOLDLOCK) where 0=1 необходимо удалить TABLOCKX HOLDLOCK.

Также необходимо удалить соответствующие хинты(подсказки блокировки) в остальных таблицах, относящихся к документам. Если этого не сделать, то будут возникать deadlock -и – взаимоблокировки транзакций на уровне SQL Server .

Предположим, что мы это сделали. Казалось бы, все теперь хорошо , документы параллельно проводятся , процессор не загружается. Но не все так просто. Что бы доказать ошибочность этих выводов, приведем следующий эксперимент.

Создадим конфигурацию : справочник — Товары, документ – ПриходнаяНакладная, документ – РасходнаяНакладная, регистр – ОстаткиТовара Приходная накладная нужна только для того что бы сделать одно единственное движение. Больше логической нагрузки она нести не будет.

В модуле расходной накладной реализуем следующую логику :

Запрос = СоздатьОбъект("Запрос");
	ТекстЗапроса =
	"//{{ЗАПРОС(Сформировать)
	|Товар = Регистр.Остатки.Товар;
	|Количество = Регистр.Остатки.Количество;
	|Функция КоличествоКонОст = КонОст(Количество);
	|Группировка Товар;
	|"//}}ЗАПРОС
	;
	Если Запрос.Выполнить(ТекстЗапроса) = 0 Тогда
		Возврат;
	КонецЕсли;
	Сообщить(НомерДок);
	Если Число(НомерДок)=1 Тогда
	Для Сч6=1 По 10000 Цикл	
		   Сообщить("Ждем второго. Вообще то здесь может идти
			 | какой-то анализ или обработка данных.
			 |Чем больше интервал между получением остатков и их
			 | анализом с последующей записью движений -
			 |тем больше вероятность возникновения отрицательных остатков");
	КонецЦИкла;
	КонецЕсли;
	Запрос.Группировка(1);
	Если (Запрос.КоличествоКонОст<0) Тогда 		
		Сообщить("Ошибка!!!");
		Возврат;          		
	КонецЕсли;	
		Если Запрос.КоличествоКонОст>=Количество Тогда
	  Регистр.Остатки.Товар=Товар;
 	 Регистр.Остатки.Количество=Количество;
	  Регистр.Остатки.ДвижениеРасходВыполнить();
	Иначе
	    Сообщить("Не хватает!");
		Возврат;
	КонецЕсли;

Товар это у меня реквизит шапки, и поэтому я использую одномерную (например использую Запрос.Группировка(1) зная что движение по одному товару) модель. Для многомерной модели ничего принципиально не меняется…

Логика вкратце сводится к тому, что необходимо, перед тем как списывать товар, провести анализ , а хватает ли его на складе? Казалось бы, при такой модели не должно возникать отрицательных остатков – ведь стоит проверка. Это возникающее на первый взгляд впечатление ошибочно. Для доказательства этого я вставил в середине модуля обработку, которая эмулирует задержку между получением остатков и их последующим анализом и записью движений. Получается следующая ситуация: когда два пользователя одновременно пытаются списать товара в сумме больше, чем есть на складе(в хронологическом порядке)

• Первый пользователь получает остатки
• Второй пользователь получает остатки
• У первого пользователя идет какая либо обработка.(в моем случае выводится сообщение)
• Второй пользователь проводит проверку остатков и списывает товар. Конец проведения.
• Первый пользователь проводит анализ остатков и тут возникает самое интересное – информация по остаткам уже устарела! Но первый пользователь об этом не подозревает , проходит проверка остатка и списание. КонецПроведения.

Возникают отрицательные остатки. С точки зрения бизнес логики, я думаю, не нужно комментировать, к чему это может привести.

Как избежать этой неприятной ситуации? – Реализовать свой, гибкий механизм блокировок.

Вот пример:

Перем глСКЛ Экспорт;
Процедура ПроверкаБлокировкиРесурса(Ресурс) Экспорт;	   
глСКЛ.Закрыть();
глСКЛ.Соединиться(0);
//глСКЛ.ВыполнитьЗапрос("set lock_timeout 20000");
	  Состояние("Проверка блокировки...");
Если Ресурс = "Регистр.ОстаткиТовара" Тогда
Если (глСКЛ.ВыполнитьЗапрос("exec MyRA17_TLockX") = 1) тогда 	
	Иначе	
	  Сообщить("Ждет Занят MyRA17_TLockX");
КонецЕсли;
Если(глСКЛ.ВыполнитьЗапрос("exec MyRG17_TLockX") = 1) тогда 	
	Иначе	
	  Сообщить("Ждет Занят MyRG17_TLockX");
КонецЕсли;
КонецЕсли;
глСКЛ.Закрыть(); 	
КонецПроцедуры        

В данном случае я блокирую по объекту метаданных Регистр.ОстаткиТовара.

А хранимые процедуры MyRG17_TLockX и MyRA17_TLockX я полностью дублирую текстом старых RG17_TLockX и RA17_TLockX.

Вставляя процедуру ПроверкаБлокировкиРесурса( «Регистр.ОстаткиТовара» ) в начало модуля проведения, мы добиваемся того, что второй пользователь ожидает, пока первый не завершит транзакцию и только после этого он может прочитать остатки товара. При этом не возникает неоправданной нагрузки процессора, и документы проводятся последовательно, но только в контексте движения по Регистр.Остатки.

Возникает вопрос: а что делать, если у нас происходит движение по бухгалтерским итогам? В этом случае движение затрагивает одну таблицу, и она становится узким местом системы.

Возникает соблазн использовать конструкцию rowlock — ведь судя по названию она и сможет устанавливать блокировку не монопольную на таблицу, а построчную на изменяемые записи.

Тут нужно во-первых понять, как хранит 1С данные и какими запросами получает данные.

Я возьму для примера только регистры. Для бухгалтерских итогов концепция будет аналогична.

Нужно отметить , что данные по регистрам хранятся в агрегированном виде т.е остатки по измерения хранятся в нескольких записях соответствующим периодичности итогов. Возникает вопрос: а не изменится ли целостность и непротиворечивость агрегированных данных при отключении стандартного механизма блокировок?

Для ответа на этот вопрос нужно во-первых понимать, что SQL Server сам расставляет блокировки объектов при изменении данных. Убедиться в этом можно, изменив в транзакции запись таблицы(как правило на индексированные) и запустив sp _ lock . По результатам sp _ lock мы увидим что данная запись заблокирована, как будто если бы мы в явном виде поставили подсказку rowlock .

Вкратце концепция изменения агрегированных данных (например регистра остатков) 1С 7.7 следующая –

При движении по регистру вызывается ряд хранимых процедур но показательные из них две это _1sp_GetNextPeriod — обеспечивает последовательное обновление агрегированных данных и _1sp_RG17_Change – собственно изменят конкретную запись. Для этого используется следующая конструкция:

Update RG17 set SP19=Case When ABS(SP19+@p3)>9999999999 Then 9999999999 Else SP19+@p3 End where PERIOD=@per AND SP18=@p1 AND SP24=@p2 if @@ROWCOUNT=0 insert into RG17 values(@per,@p1,@p2,@p3)

Как мы видим, в конструкции Update нет хинта rowlock . Но по большому счету он и не нужен т.к. сервер сам расставляет блокировки по измененным записям. В этом опять-таки не сложно убедиться, если провести ряд тестов, вкратце их смысл — искусственно создать ситуацию, при которой одна сессия будет изменять запись и другая ее будет изменять, но на основании прочитанных ранее устаревших данных. Вставка новых записей в агрегационную таблицу по документу происходит, как правило не более одной(если конечно точка актуальности не установлена абы как) и соответственно ситуация когда один документ делает вставку( insert into RG 17 values (@ per ,@ p 1,@ p 2,@ p 3) ) а другой ее не видит практически невозможна(кроме того, стоит ограничение на уровне уникальности индекса, для возможной повторной вставки).

Теперь что касается грязного чтения. С этим дело обстоит хуже и к сожалению никакие установки rowlock в этом не помогут. Во-первых, информация по изменению должна пройти по всем агрегационным записям в пределах транзакции(хоть и маловероятно что в этот момент возникнет конфликт). Во-вторых, 1С в запросах использует хинт nolock , что вообще не оставляет шансов на создание универсального блокировочного механизма. Да и нужен ли он?

Обращаясь к примеру с созданием процедуры ПроверкаБлокировкиРесурса продолжая аналогию, можно прийти к выводу о достаточности реализации блокировки объекта данных. Ну например, если мы хотим , что бы блокировалась не целиком таблица проводок, а например, только информация, связанная со счетом 41 и 004, то нам достаточно заблокировать объект СчетПоКоду(«41») и СчетПоКоду(«004»). То есть если мы знаем, что расходная накладная использует данные по 41 и 004 счетам нам достаточно вставить в начале модуля проведения процедуру ПроверкаБлокировкиОбъекта(« СчетПоКоду(«41») ») и ПроверкаБлокировкиОбъекта(« СчетПоКоду(«004») ») .

Если же мы знаем, что для нас принципиальна информация по остаткам товара на складе, то соответственно ПроверкаБлокировкиОбъекта(« Склад ») . Таким образом, все документы по одному складу будут проводиться по очереди, а по разным складам параллельно. То же самое, если мы хотим сделать блокировки по Товару. Тогда будет соответственно ПроверкаБлокировкиСпискаОбъектов(спТовара) – но в этом случае нужно понимать, что чем больше информации по блокировкам, тем больше нагрузка на сервер. Необходимо найти золотую середину.

Собственно, а как все вышеперечисленное реализовать. Вариантов несколько. Но раз мы уже остановились на классическом блокировочном механизме MS SQL, то можно воспользоваться процедурой sp_getapplock. Смысл ее в следующем – блокировка произвольного ресурса. Запустив sp _ lock мы можем убедиться, что это всего лишь еще одна запись. То есть например блокировку по складу(в контексте остатков по складу) можно сделать следующим образом sp_getapplock ‘Остатки**Склад**Основной’, ‘Exclusive’, ‘transaction’ . Соответственно аналогичная процедура выполненная из Сессии №2 сессии будет ждать завершения транзакции открытой Сессией №1 если в ней была запущенна sp_getapplock такими же параметрами. Процедура ПроверкаБлокировкиОбъекта всего лишь преобразует объект в уникальный идентификатор и передает его в качестве параметра в sp_getapplock в открытой сессии 1С 7.7.

В конце статьи хочется отметить, что для того чтобы реализовать механизм «гибких» блокировок, необходимы какие-либо навыки в MSSQL Server, а также понимание внутренней структуры 1С 7.7. Например снимая хинты с процедуры _1sp__1SSYSTEM_TLock вы тем самим можете попасть в ситуацию когда два проведенных документа перемещающие ТА проведутся одновременно и один из них окажется позже точки актуальности или наоборот сняв хинты с _1sp__1SJOURN_TLock и не сняв их с _1sp_DT???_TLockX вы можете создать deadlock -и.

При использовании материалов данной статьи обязательна ссылка на информационный ресурс.

По интересующим Вас вопросам просьба обращаться на softpoint@softpoint.ru

Статьи  по этой теме:

Что такое ошибка при транзакции, выполняемой другим пользователем? 

«Внутренние» блокировки в 1С

Технология «Гибкие блокировки»

Экономическая эффективность внедрения технологии «Гибкие блокировки»

Как внедрить

Перепечатка, воспроизведение в любой форме, распространение, в том числе в переводе, любых материалов с сайта www.softpoint.ru возможны только с письменного разрешения компании «СофтПоинт». Это правило действует для всех без исключения случаев, кроме тех, когда в материале прямо указано разрешение на копирование (основание: Закон Российской Федерации «Об авторском праве и смежных правах»).