Типа продолжение.

Есть:
1. 1С SQL 7.70.0.25.
2. Microsoft SQL Server  2000 - 8.00.2055 (Intel X86).
3. В процесе разработки собственного механизма блокировок возникла следующая проблемма. Необходимо при проведении документа который участвует в опер. учете (формирует движения по регистрам) разработать механизм исключающий взаимоблокировки.

Взаимоблокировки возникают при вызове хран. процедур вида "_1sp_RG####_Change" где есть тот же "Update RG####".

Спасибо.

Принципиальная разница как раз есть - у регистров всё гораздо проще и с UPDATE бороться не нужно.

_{Как-то вы странно к вопросу подходите..} 

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

berezdetsky писал(а) 23. Сентября 2009 :: 13:42:


Это как же, как раз проблема с UPDATE и имеет место. Два документа по одним и тем же измерениям, по одному и тому же периоду "хотят" проапдейтить итог. Взаимоблокировка не избежна... Или я чего то не понимаю?

chicago писал(а) 23. Сентября 2009 :: 13:56:


Что то ты не того говоришь
Ситуация1
Есть Док1 в нем товар1 склад1 приход +100
Есть Док2 в нем товар1 склад1 приход +300
Начинаем их одновременно проводить
Пусть Док1 начал раньше
1. update rg +100
2.Пока не закончиться транзакция по Док1 Док2
ждет для update по блокировке индекса
3.Док1 завершили
4.Док2 делает Док2 + 300
Все ок
никаких взаимоблокировок нет в принципе

Единстевенное но
в rg нет этого движения
1. док1 начинает делать update
update не удалось
2. док2 начинает делать update
update не удалось
3. док1 делает insert все ок
4док2 делает insert и вываливается по ошибке так как индекс не уникальный.

(chicago)
пост 7 не осилил.
также не понятно о каких таблицах речь о доп таблицах
или о родных 1с.

Z1 писал(а) 23. Сентября 2009 :: 14:08:


1. Да все это как раз и делается, что бы Док2 "не ждал" завершения транзакции Док1 (это о Ситуации1), а мог проводится паралельно с Док1 ибо таких "Док2" может быть весьма не мало.
2. На счет "все ок никаких взаимоблокировок нет в принципе" немогу согласиться, но спорить не буду.

classic писал(а) 23. Сентября 2009 :: 14:54:


Пожалуйста

BEGIN TRAN

SET NOCOUNT ON
SET LOCK_TIMEOUT 500
DECLARE @РезБло smallint
SELECT @РезБло = 1
FROM dbo._1SBKTTLC AS ТабБло WITH (TABLOCKX, HOLDLOCK)
IF @РезБло <> 1
ROLLBACK TRAN
DECLARE @DATE_Ins DATETIME
DECLARE @ACCDTID_Ins CHAR(9)
DECLARE @ACCKTID_Ins CHAR(9)
DECLARE @CURRID_Ins CHAR(9)
DECLARE @KIND_Ins CHAR(1)
DECLARE @OB1_Ins NUMERIC(14, 4)
DECLARE @OB2_Ins NUMERIC(14, 4)
DECLARE @OB3_Ins NUMERIC(14, 4)
DECLARE @DTFLAGS_Ins TINYINT
DECLARE @KTFLAGS_Ins TINYINT
DECLARE TabCur CURSOR FOR
	SELECT
		DATE
		, ACCDTID
		, ACCKTID
		, CURRID
		, KIND
		, SUM(OB1) AS OB1
		, SUM(OB2) AS OB2
		, SUM(OB3) AS OB3
		, DTFLAGS
		, KTFLAGS
	FROM dbo._1SBKTTLC_Ins AS _1SBKTTLC_Ins WITH (TABLOCKX, HOLDLOCK)
	GROUP BY
		DATE
		, ACCDTID
		, ACCKTID
		, CURRID
		, KIND
		, DTFLAGS
		, KTFLAGS
	HAVING
		(SUM(OB1) <> 0) OR
        (SUM(OB2) <> 0) OR
        (SUM(OB3) <> 0)
OPEN TabCur
WHILE @@FETCH_STATUS = 0
BEGIN
	FETCH NEXT FROM TabCur INTO
	@DATE_Ins
	, @ACCDTID_Ins
	, @ACCKTID_Ins
	, @CURRID_Ins
	, @KIND_Ins
	, @OB1_Ins
	, @OB2_Ins
	, @OB3_Ins
	, @DTFLAGS_Ins
	, @KTFLAGS_Ins
	UPDATE dbo._1SBKTTLC
		SET
			OB1 = OB1 + @OB1_Ins,
			OB2 = OB2 + @OB2_Ins,
			OB3 = OB3 + @OB3_Ins,
			DTFLAGS = @DTFLAGS_Ins,
			KTFLAGS = @KTFLAGS_Ins
		WHERE
			(DATE = @DATE_Ins) AND
			(KIND = @KIND_Ins) AND
			(ACCKTID = @ACCKTID_Ins) AND
			(ACCDTID = @ACCDTID_Ins) AND
			(CURRID = @CURRID_Ins)
	IF @@ROWCOUNT = 0 BEGIN
		INSERT INTO dbo._1SBKTTLC VALUES
		(
			@DATE_Ins, @ACCDTID_Ins, @ACCKTID_Ins, @CURRID_Ins, @KIND_Ins, @OB1_Ins, @OB2_Ins, @OB3_Ins, @DTFLAGS_Ins, @KTFLAGS_Ins
		)
	END
END
CLOSE TabCur
DEALLOCATE TabCur
DELETE FROM dbo._1SBKTTLC_Ins
COMMIT TRAN
SET NOCOUNT OFF
 

Никаких гарантий, что это правильно и будет быстрее.