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

При проведении документа, при вызове метода

Операция.Записать(); 

выполняется одна из хран. процедур, а именно "_1sp__1SBKTTLC_ChangeTotal".
В тексте данной процедуры есть

...
Update _1SBKTTLC
set
OB1=OB1+@Ob1,
OB2=OB2+@Ob2,
OB3=OB3+@Ob3,
DTFLAGS=@DtFlags,
KTFLAGS=@KtFlags
where
DATE=@Date and KIND=@Kind and ACCKTID=@AccKtId and ACCDTID=@AccDtId and CURRID=@CurId
... 

.
4. Вопрос(ы):
1. Почему при выполнении даной процедуры с параметрами
@Date = Дат1;
@Kind = Вид1;
@AccKtId = СчК1
@AccDtId = СчД1
@CurId = Вал1
следующим запросом

SET LOCK_TIMEOUT 500
DECLARE @РезБло smallint
SELECT @РезБло = 1
FROM _1SBKTTLC AS ТабБло WITH (INDEX(PK__1SBKTTLC), ROWLOCK, XLOCK)
WHERE
(ТабБло.DATE = Дат1) AND (ТабБло.ACCDTID = СчД3) AND (ТабБло.ACCKTID = СчК4) 

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

FROM _1SBKTTLC AS ТабБло WITH (INDEX(PK__1SBKTTLC), ROWLOCK, XLOCK,HOLDLOCK)
?

chicago писал(а) 18. Сентября 2009 :: 16:10:


вот пример
http://www.1csql.ru/materials/articles/develop.html~bafd447e-bdfd-2e14-40e6-8501...

classic писал(а) 21. Сентября 2009 :: 07:59:

1C++ v3.0.1.23 - не вылетает.

classic писал(а) 21. Сентября 2009 :: 07:59:


А зачем удалять то? Можно:
- оставить таблицу _1SBKTTL;
- сделать свое представление, например "_1SBKTTL_vw";
- поправить в BkEnd.dll все "1SBKTTL" на "_1SBKTTL_vw".

berezdetsky писал(а) 21. Сентября 2009 :: 08:59:


Как мне видится, модель (для "_1SBKTTL") такова:
- создаем таблицу "_1SBKTTL_ins";
- в хран. проц. "_1sp__1SBKTTL_ChangeTotal" убираем "Update" и все перенапрявляем в "_1SBKTTL_ins" как "INSERT INTO";
- поскольку в "_1SBKTTL" у нас в рабочее время не будет акт. итогов делаем представление "_1SBKTTL_vw". В этом предсталении будут итоги из табл. "_1SBKTTL", но с учетом "_1SBKTTL_vw";
- заменяем в BkEnd.dll все "1SBKTTL" на "_1SBKTTL_vw";
- пишем скрипт, который по шедулеру (в не раб. время) будет переносить все данные из "_1SBKTTL_ins" в "_1SBKTTL".

Все. Да в мон. режиме это все лишнее.

classic писал(а) 21. Сентября 2009 :: 13:07:


Кто мешает (запрещает) написать механизм проверки (верификации) загрузки нужной dll? Так сказать "защиту от дурака" или от "шибко умного пользователя"?
В глоб. модуле, при начеле работы проверка dll, если "не та" - иди кури. В чем вопрос то?

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

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

Это все имеет смысл, если ты оключишь блокировки в базе.
Тогда если проводятся 2 разные документа - они не будут натыкаться на журнал документов. НО: велика вероятность того, что им обоим придется обновить одинаковые строки в таблицах kttl, kttlc.
Сейчас часто получается так, что эти строки обновляются неверно, одно из одновременных изменений теряется. 10 + 5 + 5 = 15.
В случае же инсертов (я надеюсь) - подобных потерь быть не должно.
По крайней мере - я это дело уже запустил на боевой базе, для проверки. 60000 строк в таблице движений. Полет нормальный, тормозов не замечено.

То есть блокировка _1sjourn просто отключена? А как быть, например, в такой ситуации:
есть остаток 2 штуки товара. Пользователь 1 проводит документ, списывает 2 штуки. Движения, которые сделал документ пользователя 1 еще не закомичены. Пользователь 2 начинает проводить свой документ, списывает тоже 2 штуки.
"Закомиченные остатки" позволяют провести документы обоим пользователям, блокировки не возникнет. В результате спишется 4 штуки товара?
Стандартная блокировка 1С заблокирует _1sjourn и не даст Пользователю 2 провести свой документ, пока не закончится проведение для Пользователя 1.

А никто не думал скажем для сокращения
времени проведения(что бух что торговля) подготавливать
все заранее в ТЗ  а в модуле проведения только проверять остатки
(если нужно ) и делать только движения из ТЗ.
Основная идея в модуле проведения операций меньше он быстрее выполняется и блокировка ( стандартная или своя )
накладывается на меньшее время.

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

Понятно, просто показалось, что если возникают случаи, когда
Цитата:

то тут как раз и ошибка в логике блокировок, т.е. обновление происходит по одним и тем же измерением(субконто), тут нужно "подождать", а не инсертить в другую таблицу. Хотя, да, зависит, конечно, от бизнеслогики(может там только услуги, например, остатки не важны..хотя все-равно стремно, имхо). Если полет нормальный, то и ладно

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

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

PS к 27 Плюс можно также сделать очередь
создаем доп таблицу

create table last_oper
(
id bigint  IDENTITY(1,1) ,
iddoc	char(9)     NOT NULL,
oper	 tinyint  NOT NULL default 1 , -- 1 проводим документ 0 отменяем проведение документа
data_dt	 datetime    NOT NULL default getdate(),
CONSTRAINT PK_last_oper PRIMARY KEY(id)
-- может быть имеет смысл добавить значение период проведения. НачМесяца(ДатаДок)
)
 

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

Каким либо образом ( задание само запускается через фиксированное время,
тригер на какую то таблицу или даем управлять подтягиванием проведением Пользователю ) обрабатываем эту очередь в порядке возрастания id ( обработанные документы из очереди удаляем )
Все процесс который  занимается этим делом никого не блокирует.
Ведь только он может менять остатки и обороты
Остальные процессы только читают.

Все тоже самое можно сделать и для регистров.
Все это вполне реально сделать(сложность будет может быть только с УРБД ).

chicago писал(а) 07. Октября 2009 :: 16:59:

С ней с УРБД всегда сложности.

Может есть за что зацепиться когда стартует подгрузка УРБД  ?
В этом весь и вопрос.

Сложности с УРБД есть большая вероятность отката всех изменений например документ блокирован кем то.

Далее когда подгружается УРБД то не выполняются модуль проведения ( и модуль отмены проведения документа ).

Если делать чистый 27 то как узнать что самый ранний документ не откатился за период нач константы изменения документов.

Если делать 27+28 то как помещать документы в очередь ?
(ведь модуль проведения не исполняется)

Как возможное из решений перед подгрузкой В sql процеcе подгрузки но уже в транзакции надо выполнить :
1.захватить монопол блокировку на таблицы журнал документов
2.создать (включить) тригер на изменение таблицы журнала документов
3.при срабатывании тригера учитывать 27 и 28

После окончания подгрузки тригер удалить ( или выключить )

Либо вместо всего этого узнавать произошла подгрузка успешно
и самим  анализировать zip файла что же мы подгрузили но
вдруг это не сработает а если 27+28 за время анализа еще попадут другие документы и порядок
очереди будет не такой - что тоже плохо.

(Захар Малиновский) Это ты о каком режиме блокировок говоришь ?
О стандартном или о чем то еще ?

Цитата:




Если свои блокировки и READPAST
что будет
пусть сейчас есть макс  id = 10
начали первое проведение из comp1
выставили READPAST
получили следущ id = 11

начали второе  проведение из comp2
выставили READPAST
получили следущ id = 11 ( тот же самый !!!)
Закончилось проведение на первом comp1
Закончилось проведение на втором comp2 -
что при этом произойдет точно не знаю либо откатимся по ошибке либо что-то еще ?

Если я ошибаюсь то поправьте меня.


PS
С помощью двух Предупреждение в модулях проведения
легко смоделировать ситуацию

chicago писал(а) 07. Декабря 2009 :: 08:25:


Так сделать, это себе вовред.  Я ж говорю - ИТОГИ начнут расходиться с суммой проводок. Несколько (два для простоты) подключений пользователей выполняющих код процедуры _1sp__1SENTRY_MaxRowID   _одновременно_  получат ,в твоём случае, rowid последнего , а НЕ СВОЕГО инсерта проводок.
Это если у тебя не более одного документа  одновременно проводится в системе тогда ты прав. Но ты в теме про отключенные стандартные блокировки 1с.

Дайте пример как можно сделать "себе вовред".
Запись проводок и пересчет итогов идет последовательно:
а).

exec sp_executesql N'Insert into _1SENTRY values( @P1,@P2,... 

б).

declare @P1 int
set @P1=0
exec _1sp__1SENTRY_MaxRowID @P1 output
select @P1 

в).

exec _1sp__1SENTRY_NewEntry... 

Какая вероятность того, что перед пунктом б). сесии №1 "вклинится" пункт а). сесии №2?

Покажите мне как можно сделать так что бы в SQL значение @@IDENTITY получить "НЕ СВОЕГО инсерта" если значения Duration пункта а). в 99% равно 0?

Спасибо.
[/quote]

Всё дело просто в том что между  а) и пунктом б)  есть  какой-то алгоритм. Т.е. какойто call , ret и еще много чего что может удлиннять промежуток времени между ИНСЕРТОМ и вызовом _1sp__1SENTRY_MaxRowID. А плюс много-задачность на терминальном сервере, приостановка процессов планировщиком.   Вопрос "А какая вероятность что ..." - ну не знаю. _Большая_ вероятность. Ибо такое у меня было.  
Два инсерта в одну и туже таблицу из двух сессий могут быть. и они могут выполниться подряд на скл сервере.

Z1 писал(а) 04. Декабря 2009 :: 16:46:


Z1, парня с надписью "God member" как то боязно расстраивать  , но твой пример я не понял.
Тут надо понять особенность отправки на сервер инсерта в 1entry и  последующего exec __1sp__1sentry_MaxRowID.
Они отправляються на сервер так что между ними сервер скл может вставить операторы других сессий.
Поєтому предлагаеться __1sp__1sentry_MaxRowID приказывать не брать во внимание (т.е. READPAST) сделанные инсерты другими сессиями (пока эти ДРУГИЕ сессии не скажут COMMIT). А ихний COMMIT будет позже нашего select max(rowid) from _1sentry (READPAST) _почти_ точно. А почти это потому что вдруг какой - то код , которого в 1с по стандарту нет, сделает инсерт и СРАЗУ commit. Вот тогда , может быть, нас не спасает READPAST. Но у меня такого нет.