Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Атомарность операций  [new]
|\/|AX
Member

Откуда:
Сообщений: 144
Добрый день всем. Требуется блокировка сущностей в бд. Проще говоря, некоторых записей в таблицах. Вопрос по сабжу. Насколько правильна данная реализация:

CREATE TABLE [dd].[ent_lock](
	[ent_lock_id] [bigint] NOT NULL,
	[ent_lock_type_id] [int] NOT NULL,
	[locked_by] [bigint] NOT NULL
 CONSTRAINT [PK_ent_lock] PRIMARY KEY CLUSTERED 
(
	[ent_lock_id] ASC,
	[ent_lock_type_id] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [FG_Data_01]
) ON [FG_Data_01]
-- *********************************
CREATE PROC [dd].[ent_lock_by_id]
		@entity_id		bigint	
		,@entity_type_id		int	
		,@locked_by		bigint=0			OUTPUT	-- zero if was unlocked
		,@locked_by_fullname	nvarchar(255)=null		OUTPUT	-- null if was unlocked
as
begin try
	insert into
		[dd].[ent_lock] (ent_lock_id, ent_lock_type_id, locked_by)
	values	(@entity_id, @entity_type_id, @locked_by)
	
	select @locked_by = 0, @locked_by_fullname = null
	-- ......
end try
begin catch
	select	@locked_by = locked_by
	from	[dd].[ent_lock]
	where
		ent_lock_id		= @entity_id
	and	ent_lock_type_id = @entity_type_id
	
	select @locked_by_fullname = -- ...
	-- ...
end catch
go
?

Если есть предложения, как это сделать лучше, то хотелось бы выслушать.
1 окт 13, 12:50    [14906282]     Ответить | Цитировать Сообщить модератору
 Re: Атомарность операций  [new]
aleks2
Guest
1. Ежели у вас не мульенами строк блокировка, то фсе придумано до вас
sp_getapplock

2. А если мульенами строк блокировка - что-то не так в консерватории.
1 окт 13, 13:38    [14906756]     Ответить | Цитировать Сообщить модератору
 Re: Атомарность операций  [new]
Гость333
Member

Откуда:
Сообщений: 3683
|\/|AX
Если есть предложения, как это сделать лучше, то хотелось бы выслушать.

Непонятно, что "это".
Вам нужны внетранзакционные блокировки? Application lock на уровне сессии по каким-то причинам не устраивает?

|\/|AX
Насколько правильна данная реализация:

Удаление записей из ent_lock в данной реализации не предусмотрено?
1 окт 13, 13:41    [14906770]     Ответить | Цитировать Сообщить модератору
 Re: Атомарность операций  [new]
invm
Member

Откуда: Москва
Сообщений: 9688
Атомарность операций обеспечивется транзакциями. Для реализации пользовательских блокировок есть sp_getapplock.
1 окт 13, 13:41    [14906772]     Ответить | Цитировать Сообщить модератору
 Re: Атомарность операций  [new]
|\/|AX
Member

Откуда:
Сообщений: 144
Есть грид. Открыт у 20 пользователей к примеру. Он апдейтится. Тут появляется строка. Ее хотят открыть на редактирование сразу все 20 человек. Открыть должен кто-то один. Остальные не могут. Блокировка не должна сниматься до тех пор, пока редактирование не завершено или не закрыто окно редактирования. Разблокировка не так важна на мой взгляд, поэтому я ее сюда не поместил.
1 окт 13, 14:05    [14906990]     Ответить | Цитировать Сообщить модератору
 Re: Атомарность операций  [new]
StarikNavy
Member

Откуда: Москва
Сообщений: 2397
|\/|AX
Есть грид. Открыт у 20 пользователей к примеру. Он апдейтится. Тут появляется строка. Ее хотят открыть на редактирование сразу все 20 человек. Открыть должен кто-то один. Остальные не могут. Блокировка не должна сниматься до тех пор, пока редактирование не завершено или не закрыто окно редактирования. Разблокировка не так важна на мой взгляд, поэтому я ее сюда не поместил.


вариант дополнительное поле-флаг не рассматривался?
а ситауции "человек открыл на редактирование и улетел в лондон"?
1 окт 13, 14:11    [14907029]     Ответить | Цитировать Сообщить модератору
 Re: Атомарность операций  [new]
|\/|AX
Member

Откуда:
Сообщений: 144
StarikNavy
вариант дополнительное поле-флаг не рассматривался?

Что меняет поле-флаг?
StarikNavy
а ситауции "человек открыл на редактирование и улетел в лондон"?

Для этого есть функционал.

StarikNavy
Атомарность операций обеспечивется транзакциями. Для реализации пользовательских блокировок есть sp_getapplock.

Я, наверное, не точно излагаюсь. Сейчас реализация с try-catch. Я хотел узнать, насколько это приемлемое решение. и как сделать лучше. отсылаете к sp_getapplock. я почитал, но еще не понял. подойдет ли он или нет.
1 окт 13, 16:34    [14908146]     Ответить | Цитировать Сообщить модератору
 Re: Атомарность операций  [new]
Уленшпигель
Member

Откуда:
Сообщений: 115
|\/|AX, а что будет, если строку отредактируют 20 раз? Это, по каким-то причинам, недопустимо?
1 окт 13, 17:59    [14908658]     Ответить | Цитировать Сообщить модератору
 Re: Атомарность операций  [new]
uaggster
Member

Откуда:
Сообщений: 980
Добавить поле таймстамп. Передавать таймстамп на клиента. Передавать его же без изменений с клиента на сервер вместе с отредактированными данными. Апдейт производить только если таймстамп, хранящийся в базе совпал с переданным с клиента.

Кто первый обновил, тот и папа :-)
1 окт 13, 21:09    [14909298]     Ответить | Цитировать Сообщить модератору
 Re: Атомарность операций  [new]
StarikNavy
Member

Откуда: Москва
Сообщений: 2397
|\/|AX
StarikNavy
вариант дополнительное поле-флаг не рассматривался?

Что меняет поле-флаг?
.


что захотите, то и меняет.
имел в виду - передали строку на редактирование, ставим "флаг"= заблокировано, и соответственно передавать/редактировать другим нельзя.
логика приложения более прозрачна, но конечно свои + и -
2 окт 13, 09:42    [14910332]     Ответить | Цитировать Сообщить модератору
 Re: Атомарность операций  [new]
uaggster
Member

Откуда:
Сообщений: 980
Кстати, вариант с тайстампом гораздо более "человечный" (это кроме того, что он более технологичный)
Если обновление от первого пользователя уже прошло, и последующие обновления, соответственно, будут отваливаться, всё равно можно дать пользователю возможность "насильно" перезаписать данные, не взирая, т.с., по особой процедуре.
К примеру: Апдейт не прошел, т.к. не совпал таймстамп. Выводим на клиенте - Бла-бла-бла, данные уже были изменены, вот измененные данные, изменить всё равно? Ну и менять данные уже не взирая на таймстамп другой процедурой, запускаемой с другими уровнями привилегий (например).

А длительные локи, любой природы на таблицы (записи / етц) - это очень, очень плохо.

StarikNavy
|\/|AX
пропущено...

Что меняет поле-флаг?


что захотите, то и меняет.
имел в виду - передали строку на редактирование, ставим "флаг"= заблокировано, и соответственно передавать/редактировать другим нельзя.
логика приложения более прозрачна, но конечно свои + и -

Вариант с полем флагом всем хорош, но ОБЯЗАТЕЛЬНО требуется какой-никакой сборщик мусора, который автоматически будет деблокировать записи либо по событию (типа реконнекта заблокировавшего пользователя, перезагрузки сервера и т.д.) и по таймауту.

Кстати, можно такие флаги в отдельную таблицу вынести.
2 окт 13, 11:35    [14911121]     Ответить | Цитировать Сообщить модератору
 Re: Атомарность операций  [new]
Гость333
Member

Откуда:
Сообщений: 3683
uaggster
Кстати, можно такие флаги в отдельную таблицу вынести.

Тогда получится в точности решение ТСа.
Правда, у него тема сборщика мусора не раскрыта. Хотя здесь это критичное место, на мой взгляд.
2 окт 13, 11:58    [14911308]     Ответить | Цитировать Сообщить модератору
 Re: Атомарность операций  [new]
|\/|AX
Member

Откуда:
Сообщений: 144
Не вижу плюсов поля флага в таблице. для каждой сущности свой скрипт блокировки. тут одна таблица блокировок и это на мой взгляд удобно
sp_getapplock делает блокировку на строку или на таблицу? из прочитанного на мсдн я этого не понял.
Я хочу уточнить, что это бизнес-блокировка на уровне пользовательского интерфейса, а не на уровне операций бд. Поведение и прочие фичи, что там выводить юзеру, хотелось бы, чтобы остались за рамками этого обсуждения. Я хотел узнать практичность данного стиля (через try catch). Если вам известен более удобный вариант, хотел бы услышать его (sp_getapplock, например, хотя применимость к этой ситуации, я еще не выяснил)

Вижу плюсы в отдельной таблице блокировок:
1. Мы не трогаем другие таблицы (в бизнес-таблице лишь необходимые данные)
2. Все блокировки в одном месте. Можно увидеть все сразу.
3. ХП для блока/анблока для всех одни.

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

Заголовок я, наверное, не тот написал. Это моя вина. Я хотел уточнить такой вопрос: сейчас один insert и в обработке иссключений есть логика. Можно ли сделать выполнение блокировки добавлением предварительной проверки select'ом наличие таковой без обработки исключительных ситуаций? Что-то мне подсказывает, что sp_getapplock не совсем правильно использовать в моем случае, вместо таблицы entity_lock, хотя, может, я и ошибаюсь. Спасибо.
3 окт 13, 19:56    [14920828]     Ответить | Цитировать Сообщить модератору
 Re: Атомарность операций  [new]
Уленшпигель
Member

Откуда:
Сообщений: 115
|\/|AX, вы скажите, чего вы добиться пытаетесь? Ваш метод он чтобы что? Чтобы первый захвативший новую запись пользователь остался единственным редактором?
3 окт 13, 21:02    [14920991]     Ответить | Цитировать Сообщить модератору
 Re: Атомарность операций  [new]
invm
Member

Откуда: Москва
Сообщений: 9688
|\/|AX
sp_getapplock делает блокировку на строку или на таблицу? из прочитанного на мсдн я этого не понял.
sp_getapplock накладывает блокировку на именованный ресурс. Семантика этого ресурса полностью зависит от вашей фантазии. Это может быть таблица, строка таблицы, бизнес-сущность, форма вашего приложения и т.д. и т.п.
3 окт 13, 23:16    [14921308]     Ответить | Цитировать Сообщить модератору
 Re: Атомарность операций  [new]
aleks2
Guest
|\/|AX
Не вижу плюсов поля флага в таблице. для каждой сущности свой скрипт блокировки. тут одна таблица блокировок и это на мой взгляд удобно

Вижу плюсы в отдельной таблице блокировок:
1. Мы не трогаем другие таблицы (в бизнес-таблице лишь необходимые данные)
2. Все блокировки в одном месте. Можно увидеть все сразу.
3. ХП для блока/анблока для всех одни.

может, я и ошибаюсь. Спасибо.


Самый главный минус - необходимость ДОПОЛНИТЕЛЬНОГО СОЕДИНЕНИЯ при проверке блокировки.
Что автоматом аннулирует 1. и 3.

Ну и табличка "з блокировками" могет быть изрядной по размеру... что не способствует.

ЗЫ. А ващето, бизнес-блокировки можно делать "как вам хоцца". Лишь бы самому нравилось.
4 окт 13, 07:21    [14921600]     Ответить | Цитировать Сообщить модератору
 Re: Атомарность операций  [new]
|\/|AX
Member

Откуда:
Сообщений: 144
Уленшпигель
|\/|AX, вы скажите, чего вы добиться пытаетесь? Ваш метод он чтобы что? Чтобы первый захвативший новую запись пользователь остался единственным редактором?

Совершенно точно! Пишут непонятно, а потом пойми их )

aleks2
Самый главный минус - необходимость ДОПОЛНИТЕЛЬНОГО СОЕДИНЕНИЯ при проверке блокировки.
Что автоматом аннулирует 1. и 3.

ХП на лок можно вставить в другую ХП на ретрив строки из бд для редактирования

aleks2
Ну и табличка "з блокировками" могет быть изрядной по размеру... что не способствует.

Не могет

invm
sp_getapplock накладывает блокировку на именованный ресурс. Семантика этого ресурса полностью зависит от вашей фантазии. Это может быть таблица, строка таблицы, бизнес-сущность, форма вашего приложения и т.д. и т.п.


Спасибо за разъяснения )
7 окт 13, 20:17    [14936107]     Ответить | Цитировать Сообщить модератору
 Re: Атомарность операций  [new]
|\/|AX
Member

Откуда:
Сообщений: 144
Всем спасибо за ответы. Вы мне помогли.
7 окт 13, 20:21    [14936122]     Ответить | Цитировать Сообщить модератору
 Re: Атомарность операций  [new]
SFlash
Member

Откуда:
Сообщений: 143
|\/|AX,

Мне одному кажется что дуло тут не принципе организации блокировки (хотя он интересен сам в себе чисто академически), а в кривом принципе организации бизнес логики введения и обработки данных?
Даже в страшном сне не могу представить ситуацию, в которой куча народу (даже 2 уже куча ;) пытается изменить одну запись одновременно. Обычно в нормальных системах данные "персонализированны", т.е. всегда в записи есть поле идентификатор, кто ввел данные или откуда пришли (если автосбор или обмен данными с другими системами), и никто не может изменить чужие данные. Ну а для отчетов они агрегируются, да, теряются персональные идентификаторы, но там и тем более, нафиг не нужна блокировка.
Поделитесь сведениями, хоть что это за процесс у Вас ?
9 окт 13, 11:18    [14943506]     Ответить | Цитировать Сообщить модератору
 Re: Атомарность операций  [new]
invm
Member

Откуда: Москва
Сообщений: 9688
SFlash
т.е. всегда в записи есть поле идентификатор, кто ввел данные или откуда пришли (если автосбор или обмен данными с другими системами), и никто не может изменить чужие данные
Ну да, ну да. Выходные, отпуски и больничные запрещены, а сотрудники прикованы к рабочим местам...
9 окт 13, 11:29    [14943606]     Ответить | Цитировать Сообщить модератору
 Re: Атомарность операций  [new]
SFlash
Member

Откуда:
Сообщений: 143
invm
SFlash
т.е. всегда в записи есть поле идентификатор, кто ввел данные или откуда пришли (если автосбор или обмен данными с другими системами), и никто не может изменить чужие данные
Ну да, ну да. Выходные, отпуски и больничные запрещены, а сотрудники прикованы к рабочим местам...


К вашему сведению, взять тот же отдел кадров, каждый сотрудник ведет свою часть организации (отделы, цеха, смены, региональные представительства и т.д. и т.п.). И на время больничного, его подменяет другой, конечно.
Если получилось что два сотрудника отдела кадров одновременно редактируют одного и того же человека, в части одной и той же записи (одновременно закрывают больничный например) - это как раз и говорит о неправильной организации кадровой работы ))).
Или есть что возразить?
10 окт 13, 09:24    [14948523]     Ответить | Цитировать Сообщить модератору
 Re: Атомарность операций  [new]
Glory
Member

Откуда:
Сообщений: 104751
SFlash
Даже в страшном сне не могу представить ситуацию, в которой куча народу (даже 2 уже куча ;) пытается изменить одну запись одновременно

Вы билеты когда-ниубдь покупали ? На поезд или на самолет, например ?
Когда десятки, а то и сотни людей одновременно хотят получить вот именно это место
10 окт 13, 09:44    [14948609]     Ответить | Цитировать Сообщить модератору
 Re: Атомарность операций  [new]
SFlash
Member

Откуда:
Сообщений: 143
Glory
SFlash
Даже в страшном сне не могу представить ситуацию, в которой куча народу (даже 2 уже куча ;) пытается изменить одну запись одновременно

Вы билеты когда-ниубдь покупали ? На поезд или на самолет, например ?
Когда десятки, а то и сотни людей одновременно хотят получить вот именно это место


А не приходило в голову что в RealTime системах нет такого, чтоб два кассира открыли все билеты, и полчаса сидят их все руками правят, вот этот я продам, вот этот тоже, а вот этот пусть МарьИванна делает. Там опрос данных, которые надо изменить, идет перед самим процессом изменения. Опять же тут первично выступает организация самого "документооборота" (в виде билетов).

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

Не надо спихивать все на программистов, сделайте нам так чтоб все могли все и сразу, но чтоб в данных порядок был!!!
Программист описывает бизнес логику в алгоритмах (C#, SQL, да хоть Basic for DOS 1.0 ), поэтому сначала приводится она в порядок, а потом описывается в программе.
10 окт 13, 10:33    [14948868]     Ответить | Цитировать Сообщить модератору
 Re: Атомарность операций  [new]
Glory
Member

Откуда:
Сообщений: 104751
SFlash
А не приходило в голову что в RealTime системах нет такого, чтоб два кассира открыли все билеты, и полчаса сидят их все руками правят, вот этот я продам, вот этот тоже, а вот этот пусть МарьИванна делает. Там опрос данных, которые надо изменить, идет перед самим процессом изменения. Опять же тут первично выступает организация самого "документооборота" (в виде билетов).

А вы резервировали отели в онлайн ? Когда я сначала бронирую номер. А потом подтверждаю. Без всяких кассиров.
10 окт 13, 10:36    [14948892]     Ответить | Цитировать Сообщить модератору
 Re: Атомарность операций  [new]
invm
Member

Откуда: Москва
Сообщений: 9688
SFlash
И на время больничного, его подменяет другой, конечно.
Ага, ага. И работает под учеткой подменяемого. Ибо
SFlash
Обычно в нормальных системах данные "персонализированны", т.е. всегда в записи есть поле идентификатор, кто ввел данные или откуда пришли (если автосбор или обмен данными с другими системами), и никто не может изменить чужие данные.
10 окт 13, 10:46    [14948979]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить