Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 непонятное поведение xlock  [new]
Леша777
Guest
BOL :
XLOCK
Specifies that exclusive locks are to be taken and held until the transaction completes. If specified with ROWLOCK, PAGLOCK, or TABLOCK, the exclusive locks apply to the appropriate level of granularity.


Подскажите пожалуйста в почему разное поведение ?

Есть таблица :

CREATE TABLE dbo.PP(
	                     id INT NOT NULL IDENTITY(1, 1)   
                              ,tp TINYINT NOT NULL 
                              ,dt DATETIME NOT NULL 
                             )
                    
 GO 
 ALTER TABLE dbo.PP ADD CONSTRAINT PK_PP PRIMARY KEY CLUSTERED (id)  


Заполняем данными :
INSERT INTO dbo.PP(tp, dt)
SELECT 1, GETDATE() 
UNION ALL
SELECT 2, GETDATE() 
UNION ALL
SELECT 3, GETDATE() 


1ая транзакция :
BEGIN TRAN 

SELECT *
FROM dbo.PP WITH(XLOCK)
WHERE pp.id = CAST(1 AS TINYINT); 

SELECT *
FROM sys.dm_tran_locks dtl
WHERE dtl.request_session_id = @@SPID

--- транзакцию не комитим !!!!


2ая транзакция :
BEGIN TRAN 

UPDATE p 
SET p.dt = GETDATE() 
FROM dbo.PP AS p WITH(XLOCK)
WHERE p.id = CAST(1 AS TINYINT); 

SELECT *
FROM sys.dm_tran_locks dtl
WHERE dtl.request_session_id = @@SPID

--- транзакцию тоже  не комитим !!!!


Почему в случае первой открытой транзакции мы можем выполнить в другой сессии следующие запросы, а в случае обновления нет ?
SELECT *
FROM dbo.PP AS p 
WHERE p.id = CAST(1 AS TINYINT)
-- или 

SELECT * 
FROM dbo.PP 


Почему XLOCK не мешает прочтению, как это делает обновление ?

Ведь данные sys.dm_tran_locks идентичные.

Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64)   Apr  2 2010 15:48:46   Copyright (c) Microsoft Corporation  Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) 
23 июн 12, 01:32    [12763615]     Ответить | Цитировать Сообщить модератору
 Re: непонятное поведение xlock  [new]
Леша777
Guest
snapshot изолячия не включена. чтения происходят в read commited.
23 июн 12, 01:37    [12763624]     Ответить | Цитировать Сообщить модератору
 Re: непонятное поведение xlock  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3274
XLock здесь не при чем - при чтении блокировки снимаются после окончания стейтмента. Хотите, чтобы удерживались до конца транзакции - добавляйте holdlock.

Пора уже в FAQ выносить, постоянно эта тема мусолится и никто не читает доку по хинтам...
23 июн 12, 03:14    [12763711]     Ответить | Цитировать Сообщить модератору
 Re: непонятное поведение xlock  [new]
invm
Member

Откуда: Москва
Сообщений: 9405
Ennor Tiegael,
http://msdn.microsoft.com/en-us/library/ms187373.aspx
XLOCK
Specifies that exclusive locks are to be taken and held until the transaction completes. If specified with ROWLOCK, PAGLOCK, or TABLOCK, the exclusive locks apply to the appropriate level of granularity.


Леша777,
http://social.msdn.microsoft.com/forums/en-US/transactsql/thread/b1138478-730a-45f9-b4b5-6736dca3c747/
Using XLOCK in SELECT statements will not prevent reads from happening.
This is because SQL Server has a special optimization under read committed isolation
level that checks if the row is dirty or not and ignores the xlock if the row has not changed.
Since this is acceptable under the read committed isolation level semantics it is by design
23 июн 12, 10:04    [12763846]     Ответить | Цитировать Сообщить модератору
 Re: непонятное поведение xlock  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3274
invm,

Я это читал буквально пару дней назад. И тем не менее, как мы все здесь прекрасно знаем, работает он не так. Как именно он работает, см. описание TABLOCK там же - до конца стейтмента при чтении, до конца транзакции при записи.

Во всяком случае, для 2005 документация идентична, и там это работает так, как я описал. Не исключено, что в 2012 таки поправили, но судя по поведению у ТС, в 2008R2 воз и ныне там.
25 июн 12, 00:36    [12767676]     Ответить | Цитировать Сообщить модератору
 Re: непонятное поведение xlock  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37068
Ennor Tiegael
invm,

Я это читал буквально пару дней назад. И тем не менее, как мы все здесь прекрасно знаем, работает он не так. Как именно он работает, см. описание TABLOCK там же - до конца стейтмента при чтении, до конца транзакции при записи.

Во всяком случае, для 2005 документация идентична, и там это работает так, как я описал. Не исключено, что в 2012 таки поправили, но судя по поведению у ТС, в 2008R2 воз и ныне там.

Да ладно вам. Все честно висит до конца транзакции.

if @@trancount > 0
    rollback
go    
use tempdb
go
if object_id('dbo.TestLocks') is not null
    drop table dbo.TestLocks
go
create table dbo.TestLocks (
    id      int             not null identity primary key
    , value varchar (50)
)

insert dbo.TestLocks(
    value
)
select '1'

begin tran

select * from dbo.TestLocks with ( xlock )

exec sp_lock @@spid

---------------------------------------------------------------------
spid   dbid   ObjId       IndId  Type Resource                         Mode     Status
------ ------ ----------- ------ ---- -------------------------------- -------- ------
75     2      2098458048  1      PAG  8:23136                          IX       GRANT
75     2      2098458048  0      TAB                                   IX       GRANT
75     2      2098458048  1      KEY  (010086470766)                   X        GRANT
75     1      1131151075  0      TAB                                   IS       GRANT

Microsoft SQL Server 2008 (SP2) - 10.0.4064.0 (X64) 
	Feb 25 2011 13:56:11 
	Copyright (c) 1988-2008 Microsoft Corporation
	Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)
25 июн 12, 10:10    [12768350]     Ответить | Цитировать Сообщить модератору
 Re: непонятное поведение xlock  [new]
invm
Member

Откуда: Москва
Сообщений: 9405
Ennor Tiegael
invm,

Я это читал буквально пару дней назад. И тем не менее, как мы все здесь прекрасно знаем, работает он не так. Как именно он работает, см. описание TABLOCK там же - до конца стейтмента при чтении, до конца транзакции при записи.

Во всяком случае, для 2005 документация идентична, и там это работает так, как я описал. Не исключено, что в 2012 таки поправили, но судя по поведению у ТС, в 2008R2 воз и ныне там.
use tempdb;
set ansi_nulls, quoted_identifier, nocount on;
go

create table dbo.Test (i int);
insert into dbo.Test values (1);
go

set transaction isolation level read committed;

begin tran;

select @@version;

select * from dbo.Test with (xlock) where i = 1;

select
 cast(object_schema_name(sp.object_id) + '.' + object_name(sp.object_id) as varchar(30)) as object,
 cast(tl.resource_type as varchar(30)) as resource_type,
 cast(tl.request_mode as varchar(30)) as request_mode,
 cast(tl.request_status as varchar(30)) as request_status
from
 sys.dm_tran_locks tl left join
 sys.partitions sp on sp.hobt_id = tl.resource_associated_entity_id
where
 tl.request_session_id = @@spid and
 tl.resource_database_id = db_id() and
 tl.resource_type = 'RID';
 
rollback;
go

drop table dbo.Test;
go
Результат:
----------------------------------------------------------------------------------------------------------
Microsoft SQL Server 2008 R2 (SP1) - 10.50.2796.0 (X64)
Dec 9 2011 11:27:20
Copyright (c) Microsoft Corporation
Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)


i
-----------
1

object resource_type request_mode request_status
------------------------------ ------------------------------ ------------------------------ ------------------------------
dbo.Test RID X GRANT


25 июн 12, 10:13    [12768357]     Ответить | Цитировать Сообщить модератору
 Re: непонятное поведение xlock  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Леша777
чтения происходят в read commited.
Надо было это в скрипт добавить.
Ваша ситуация не воспроизводится. У меня локируется в обоих случаях.
Microsoft SQL Server 2008 (SP3) - 10.0.5500.0 (X64)

Ennor Tiegael
XLock здесь не при чем - при чтении блокировки снимаются после окончания стейтмента. Хотите, чтобы удерживались до конца транзакции - добавляйте holdlock.
Чушь неполная.
XLock определяет тип бокирования (монопольная), HoldLock - подразумевает стратегию чтения (уровень SERIALIZABLE).
Можно влиять на стратегию чтения, на стратегию изменения нельзя - она всегда монопольная (т.е. до конца транзакции).

Некоторые типы локировок совместимы.

Есть нюансы. Иногда (в военное время, когда крокодилы летять низенько-низенько) можно прочитать залоченные данные, если страница данных в итоге не поменялась.
25 июн 12, 10:49    [12768602]     Ответить | Цитировать Сообщить модератору
 Re: непонятное поведение xlock  [new]
Леша777
Guest
invm, спасибо огромное за ссылку.

Mnior
Ваша ситуация не воспроизводится. У меня локируется в обоих случаях.


Что оба чтения ждут конца транзакции с XLOCK ?

Проверил на 2005 и тоже чтения проходят.
25 июн 12, 11:09    [12768769]     Ответить | Цитировать Сообщить модератору
 Re: непонятное поведение xlock  [new]
invm
Member

Откуда: Москва
Сообщений: 9405
Леша777,

У меня, кстати, тоже не воспроизводится. Вернее, воспроизводится с S-локами всегда, а с X-локами нет. Например, на поведение влияет наличие блобов в таблице.
25 июн 12, 11:41    [12769064]     Ответить | Цитировать Сообщить модератору
 Re: непонятное поведение xlock  [new]
nezhadnye_my
Guest
у меня воспроизводится.
в обоих случаях висит X до конца транзакции.
в случае селекта дает прочесть, в случае апдейта не дает

но, как написал invm:
This is because SQL Server has a special optimization under read committed isolation
level that checks if the row is dirty or not and ignores the xlock if the row has not changed.

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

BEGIN TRAN 

UPDATE p 
SET p.dt = p.dt 
FROM dbo.PP AS p WITH(XLOCK)
WHERE p.id = CAST(1 AS TINYINT); 


тогда и оно даст прочесть
25 июн 12, 11:57    [12769222]     Ответить | Цитировать Сообщить модератору
 Re: непонятное поведение xlock  [new]
Леша777
Guest
Вообще странное поведение :

действительно после обновления, если ничего не поменялось, то читается.

BEGIN TRAN 

UPDATE p 
SET p.dt = p.dt
FROM dbo.PP AS p WITH(XLOCK)
WHERE p.id = CAST(1 AS TINYINT); 


А так уже нет :

BEGIN TRAN 

UPDATE p 
SET p.dt = GETDATE()
FROM dbo.PP AS p WITH(XLOCK)
WHERE p.id = CAST(1 AS TINYINT); 
25 июн 12, 12:27    [12769550]     Ответить | Цитировать Сообщить модератору
 Re: непонятное поведение xlock  [new]
invm
Member

Откуда: Москва
Сообщений: 9405
Леша777,

The Impact of Non-Updating Updates
25 июн 12, 12:57    [12769813]     Ответить | Цитировать Сообщить модератору
 Re: непонятное поведение xlock  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
OffTop
invm
The Impact of Non-Updating Updates
Ящик пандоры, IMXO.
Точнее очередной гвоздь в гроб разработки скуля. Ещё чуть чуть и побочные эффекты сведут разработчиков с ума.

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

У меня есть предположение, что индксированные представления как раз сыграли тем фактором появления этого костыля (т.к. именно там и спамится монопольными локировками).
25 июн 12, 15:21    [12771259]     Ответить | Цитировать Сообщить модератору
 Re: непонятное поведение xlock  [new]
invm
Member

Откуда: Москва
Сообщений: 9405
Mnior,

ИМХО, с точки зрения неосведомленного разработчика вот это
http://social.msdn.microsoft.com/forums/en-US/transactsql/thread/b1138478-730a-45f9-b4b5-6736dca3c747/
Using XLOCK in SELECT statements will not prevent reads from happening.
This is because SQL Server has a special optimization under read committed isolation
level that checks if the row is dirty or not and ignores the xlock if the row has not changed.
Since this is acceptable under the read committed isolation level semantics it is by design
гораздо хуже.
25 июн 12, 15:53    [12771564]     Ответить | Цитировать Сообщить модератору
 Re: непонятное поведение xlock  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
invm
Mnior
invm
The Impact of Non-Updating Updates
Ящик пандоры.
с точки зрения неосведомленного разработчика вот это
http://social.msdn.microsoft.com/forums/en-US/transactsql/thread/b1138478-730a-45f9-b4b5-6736dca3c747/
Using XLOCK in SELECT statements will not prevent reads from happening.
This is because SQL Server has a special optimization under read committed isolation
level that checks if the row is dirty or not and ignores the xlock if the row has not changed.
Since this is acceptable under the read committed isolation level semantics it is by design
гораздо хуже.
А резве в первоначальной ссылке не об этом?

Я тут подумал, что всё-таки лучше стоит иметь ввиду такие вещи:
1. Банально более внимательно относится к выбору изоляции транзакций для каждой команды и каждого объекта в ней.
2. Следить за тем что меняешь, не было такого что данные фактически не менялись.
3. В критических секция особенно, т.е. локировать строки явным изменением.

Но, последний пункт вызывает сомнения. Неужели нельзя сделать локирующий селект, а потом уже в зависимости от ситуации?
Т.е. получается это считается как "вредная привычка" и блокировка это должно быть синонимом изменение.
Т.е. нужно в крайнем случае явно добавлять поле State.

Неужели SELECT FOR UPDATE является порочным программированием с любой точки зрения как ни крути?

PS: Это я к тому чтоб дальше не было вопросов почему "сливают карму" за употребление принципа SELECT FOR UPDATE. Для консенсуса.
9 июл 12, 01:30    [12836628]     Ответить | Цитировать Сообщить модератору
 Re: непонятное поведение xlock  [new]
invm
Member

Откуда: Москва
Сообщений: 9405
Mnior
1. Банально более внимательно относится к выбору изоляции транзакций для каждой команды и каждого объекта в ней.
Безусловно. Только вот неуклонно растет число разработчиков, для которых TIL, ACID и т.п. -- пустой звук.
Mnior
2. Следить за тем что меняешь, не было такого что данные фактически не менялись.

Долой многостобцовый UPDATE? Ну и, кстати, ваше предположение насчет костыля вот отсюда 12771259, не оправдалось. Вот жертва -- https://www.sql.ru/forum/actualthread.aspx?tid=951811&pg=-1

Mnior
Неужели SELECT FOR UPDATE является порочным программированием с любой точки зрения как ни крути?
В природе не существует "палки Мёбиуса" :) SELECT FOR UPDATE всего лишь один из инструментов.
9 июл 12, 11:01    [12837397]     Ответить | Цитировать Сообщить модератору
 Re: непонятное поведение xlock  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
invm
Mnior
1. Банально более внимательно относится к выбору изоляции транзакций для каждой команды и каждого объекта в ней.
Безусловно. Только вот неуклонно растет число разработчиков, для которых TIL, ACID и т.п. -- пустой звук.
Может быть этот недуг уже поразил разрабов скуля.

invm
Mnior
2. Следить за тем что меняешь, не было такого что данные фактически не менялись.

Долой многостобцовый UPDATE?

Имеется ввиду за логикой всей системы следить. Какого фига это данные не поменялись. Чё на клиенте тяжело проверить? И т.п.
Хотя я имею ввиду иммено в критических секции в первую очередь.
Ну тут опять ваш ответ из первого пункта. :)

invm
Ну и, кстати, ваше предположение насчет костыля вот отсюда 12771259, не оправдалось. Вот жертва -- https://www.sql.ru/forum/actualthread.aspx?tid=951811&pg=-1
Шо за фигня.
А. Причём тут реликация транзакций к оптимизации блокировок.
Если бы ещё в логах не создавалать запись, что строка поменялась (на тоже значение), я б вообще за последствия тотального песца не ручался.
Б. Это уже проблема к оптимизации индексированных представлений, строка inserted+deleted таблицах есть? есть! - значит надо обновить.
Может зарегать на connection ?

... Дошло. Вы имеете ввиду, что если это была проблема чисто индексированных, то они бы их оптимизнули ?
Не, тут другое. Тут источник проблемы не таблицы на которых висят индексированные, а сами индексированные, т.к. обновление в одной таблице накладывает 100500 X локировок на все другие связанные таблицы, и поэтому лочит параллельные процессы.

invm
Mnior
Неужели SELECT FOR UPDATE является порочным программированием с любой точки зрения как ни крути?
В природе не существует "палки Мёбиуса" :) SELECT FOR UPDATE всего лишь один из инструментов.
Что-то у вас летнее натроение, ффилософфия в лирику перешла. :)
Не, я серьёзно. Мне лично кажется всётаки логика MS обоснованным. Точнее "реализация" конечно тотальное говно (ну меняйте хоть один несущественный битик на странице, лять). А вот логика в случае SELECT FOR UPDATE нет.
Всётаки можно разделить на две вещи:
1. Получение первоначальных данных (логика данных)
2. Упорядочивание процессов (логика процессов)
Получается смешение этих понятий в одну реализацию оказалось плохим решением.

Вы можете привести обоснованный случай применения SELECT FOR UPDATE без которого становится нереально сложно ? Что-то меня память и логика подводит сейчас.

PS: Уже два прежложения на coonection. :)
9 июл 12, 14:06    [12838722]     Ответить | Цитировать Сообщить модератору
 Re: непонятное поведение xlock  [new]
invm
Member

Откуда: Москва
Сообщений: 9405
Mnior
Имеется ввиду за логикой всей системы следить. Какого фига это данные не поменялись. Чё на клиенте тяжело проверить? И т.п.
Кто ж за ней следить будет? Это же надо писать. Гораздо проще и дешевле доверится используемому DAL -- он сам все нагенерит. А то, что нагенеренное порой малоэффективно, мало кого волнует.
Mnior
Дошло. Вы имеете ввиду, что если это была проблема чисто индексированных, то они бы их оптимизнули ?
Не, тут другое. Тут источник проблемы не таблицы на которых висят индексированные, а сами индексированные, т.к. обновление в одной таблице накладывает 100500 X локировок на все другие связанные таблицы, и поэтому лочит параллельные процессы.
Ну а как иначе актуализировать индексированные представления?
Mnior
Вы можете привести обоснованный случай применения SELECT FOR UPDATE без которого становится нереально сложно ? Что-то меня память и логика подводит сейчас.
Навскидку не могу. Но это не значит, что таковых нет вообще :)
9 июл 12, 16:45    [12839980]     Ответить | Цитировать Сообщить модератору
 Re: непонятное поведение xlock  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
SELECT FOR UPDATE -> SFU (давно пора)

invm
Кто ж за ней следить будет? Это же надо писать. Гораздо проще и дешевле доверится используемому DAL -- он сам все нагенерит. А то, что нагенеренное порой малоэффективно, мало кого волнует.
У нас эмоциональная фаза пессимизма видимо когерентна (совпадает). :)

invm
Mnior
Не, тут другое. Тут источник проблемы не таблицы на которых висят индексированные, а сами индексированные, т.к. обновление в одной таблице накладывает 100500 X локировок на все другие связанные таблицы, и поэтому лочит параллельные процессы.
Ну а как иначе актуализировать индексированные представления?
Ок. Вариант что виновниками стали индексированные остаётся.

Как сделать лучше чем сделало M$?
Вот кстатит об этом: 12607341
А ХЗ, всё вроде нормально, M$ всё сделано правильно, IMXO. Мне тоже кажется что это лучшее решение.
Тут надо очень точно уточнить виды блокировок. Есть пониятие "изменение" и есть понятие "намерение".
Надо ещё подумать.

invm
Mnior
Вы можете привести обоснованный случай применения SFU без которого становится нереально сложно ? Что-то меня память и логика подводит сейчас.
Навскидку не могу. Но это не значит, что таковых нет вообще :)
Кажись вспомнил в чём проблема (ну я туплю сегодня): Любые изменения, для которых надо предварительно считывать данные (Те же счётчики, индексированные представления ...). Т.е. проблема взаимоблокировки.

Сначало банально - чем сейчас гарантируется атомарность команд? Представим, что ест некий сложный UPDATE.
Считывает он данные - потом считает, считает, считает (типа подсчёт += 1 путём взятия интеграла по контуру :) ), а потом записывает сие сложное вычисление. Допустим таких вычисления параллельно несколько. Тогда как гарантируются что оно не заблокируются? Просто - нельзя параллеьно налажить два UpdLock, да - считать можно, но наложить нельзя (блокировка намерения).

Т.е. всё нормально - проблемы нет. И SFU будет консестивен с любым другим SFU. И не будет взаимоблокировки.

ОК, тогда я уточню вопрос: Для чего нужно локировать строку путём SFU но при этом не давать делать банальное чтение (без намерения изменения) ?
Зачем оно надо?

+ Личные заметки на полях :)
Любая локировка на физическом уровне (такова природа, а не реализация) работает через состояние.
Т.е. выбирается некое поле которое читается перед изменением, и если .... <теория много-поточной блокировки + теория консистентного изменения>
До недавнего времени это были идентификаторы транзакций + таблицы локировок, которые палюбе считались.
Щас же это уже не так, и оно перешло на проверку состояния страницы (была изменена или нет). Но оно работает "немного" неправильно ...

Коль SFU это так же есть смена состояние объекта ("ща сия сущность будет что-то мутить, ждите"), и оно используется для синхронизации потоков (в основном), то КО подсказывает, что должно быть изменение (где-то там).
Проблема всего лишь в том, что для SFU это состояние совершенно нигде не видно, нельзя сказать, что оно было специально заблокированно и именно для данного состояния, их же может быть и несколько (и размазано по коду).
И это непонятность не есть Тру.

Спрашивается накуя делается SFU, когда понятней и логичней сделать банальный UPDATE-ы с явным указанным состоянием ("синхронизирую с системой A", '"откатываю нафиг" и т.п.). Да оно не будет видно для некоторых парралельных процессов. Зато будет видно в текущем или для UnCommitted.

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

Тем самым мы (и M$) в дальнейшем читаем что база отвечает только за консистентность данных, но не процессов.
Фу. Отчитался.
9 июл 12, 20:25    [12841137]     Ответить | Цитировать Сообщить модератору
 Re: непонятное поведение xlock  [new]
Леша777
Guest
ОК, тогда я уточню вопрос: Для чего нужно локировать строку путём SFU но при этом не давать делать банальное чтение (без намерения изменения) ?
Зачем оно надо?


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

Решил вопрос обновлением с самого начала транзакции.

Самое дикое в этой теме для меня разница в поведении :

BEGIN TRAN 

UPDATE p 
SET p.dt = p.dt
FROM dbo.PP AS p WITH(XLOCK)
WHERE p.id = CAST(1 AS TINYINT); 


и

BEGIN TRAN 

UPDATE p 
SET p.dt = p.dt
FROM dbo.PP AS p 
WHERE p.id = CAST(1 AS TINYINT); 


В первом случае ничего не меняем, но не читаются, во втором - читаются.
9 июл 12, 22:16    [12841442]     Ответить | Цитировать Сообщить модератору
 Re: непонятное поведение xlock  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Леша777, в том-то и дело.
Вот вы отвлекитесь, забудьте что вы программист и "кул-хацкер", настройтесь что вы простой обыватель и читаете совершенно чужую для вас задачу: 12841442.
Вам не кажется что автор сего поста нормально не может формализовать поставленую задачу. Но это ладно, он написал дикую ахинею, аж смешно. Вам не кажется?

А вот так оно как-то банально нормальнее смотрится, не говоря о самом её решении:
+
BEGIN TRAN TJackpot;

UPDATE	P 
SET	State	= 'Джекпот'	-- Или идентификатор состояния
FROM	dbo.PP	P 
WHERE	P.ID	= @ID;

-- Мега сложный процесс Bla-bla-bla

UPDATE	P 
SET	State	= 'А нифига'	-- Или идентификатор состояния
--	,<набор "обработанных" полей>
FROM	dbo.PP	P 
WHERE	P.ID	= @ID;

-- COMMIT TRAN TJackpot;
-- ROLLBACK; -- В зависимости от логики/задачи

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

Так вот, вернёмся к вашей задаче - "ответу" на мой вопрос. Вы прочитайте мой вопрос ещё раз и скажите, где в вашей задаче есть обоснованный пример того что "читать данные нельзя"? А в этом то и суть вопроса.
Слово "обязательно" не есть аргумент, это синоним "априори" т.е. совершенно бессмысленно для моего вопроса.
Так что обе части моего вопроса не удовлетворены (нет никакого SELECT FOR UPDATE, нет никакого простого чтения, которое должно блокироваться).

А вот если бы вы описали реальную задачу (из реального физического мира), и в ней было видно, что именно так она должна быть реализована, то этот пост был-бы ценным.
10 июл 12, 00:18    [12841791]     Ответить | Цитировать Сообщить модератору
 Re: непонятное поведение xlock  [new]
invm
Member

Откуда: Москва
Сообщений: 9405
Mnior, а что в вашем понимании SELECT FOR UPDATE?

Потому что в моем понимании
Mnior
локировать строку путём SFU но при этом не давать делать банальное чтение
есть X-блокировка.
10 июл 12, 01:11    [12841963]     Ответить | Цитировать Сообщить модератору
 Re: непонятное поведение xlock  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Чтобы ответить на вопрос, нужно перечислить типы задач, которые могут возникать:
1. Тупая запись поверх. (Независимость данных)
2. Инкрементальная запись (функциональная само-зависимость)
3. Вывод одних данных от других (зависимость одних данных от других)
4. ...

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

+ Встречный вопрос на засыпку
Есть строка с полем State = 1.
Начинается транзакция и это значение меняется на 2.
Что должен делать параллельный процесс читающий данные (TIL = RC), где в условии присутствует выражение State = 3?
1. Ждать первый процесс пока тот не освободит строку
2. Пропустить строку, как не удовлетворяющую условию
?
10 июл 12, 02:05    [12842055]     Ответить | Цитировать Сообщить модератору
 Re: непонятное поведение xlock  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
invm
Mnior, а что в вашем понимании SELECT FOR UPDATE?
Оторвитесь от реализации скуля.
Да это X, но это не важно, важно именно задача как таковая:
Использование блокировки без изменения данных, но с запрещением чтения.

Я придумать не могу. Точнее оно не входит в понятие Консистентности данных, IMXO.
Любая задача решается без данного "механизма". Выше я показал, как оно свободно заменяется. Но я иду дальше: Любой вариант использующий данный "механизм" SFU выглядит абсурднее, чем явная команда UPDATE (как я показал выше).
Согласны?

PS: На самом деле реальный SFU разрешает чтение, но я не об этом.
10 июл 12, 02:37    [12842087]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить