|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Nik Sestrin 2:5020/400 22 Aug 2002 20:06:52
To : Vladimir Pavlikov
Subject : Re: Отчеты
--------------------------------------------------------------------------------
"Vladimir Pavlikov" <pvv@soil.msu.ru> wrote in message
news:ak31c5$4ap$3@host.talk.ru...
> Hello, Nik Sestrin!
> You wrote to Vladimir Pavlikov on Thu, 22 Aug 2002 14:39:46 +0000 (UTC):
>
> >> _Два_ запроса. Сериализация (которая поставит всех остальных раком)
> >> здесь не поможет, тут нужен snapshot.
>
> NS> хоть десять ... дока гарантирует решение проблемы фантомов если
> NS> сказать set transaction isolation level serializable , опыт/тесты
> NS> подтверждают...
>
> Доку стоит читать внимательнее :
> Serializability requires that any query executed during a transaction
> must obtain the same set of rows if it is executed again at some later
> ^^^^^^^^^^^^^^^^^^^^
> point within the same transaction.
я читаю
The REPEATABLE READ clause now does not necessarily protect against
phantoms. Serializable transactions, set using the SERIALIZABLE clause of
SET TRANSACTION ISOLATION LEVEL, allow less concurrency than the REPEATABLE
READ clause because they protect against phantoms.
Expect different results as compared to earlier versions of SQL Server. Many
applications only need REPEATABLE READ semantics for correct operation. Use
the REPEATABLE READ clause of SET TRANSACTION ISOLATION LEVEL for
applications requiring REPEATABLE READ semantics but that do not need
phantom protection. If phantom protection is required, use the SERIALIZABLE
clause.
> зения нужен. То же касается и тестов. Речь не о вещах, которые
> приведут к проблемам обязательно, а о тех, которые могут вылезти
> в недетерминированный момент времени. И ждать его можно годы.
> А можно и часы :)
>
> NS> Vladimir Pavlikov/Liliya Huff могут привести пример для mssql,
> NS> когда это не так?
>
> Как ты себе представляешь эти примеры? Это же не структура базы и
> текст запроса только, это еще и ситуация.
если нет прецедентов и дока утверждает обратное - извини, я ей
верю....больше
простейший тест:
в 1 сеансе:
create table q (id int)
insert into q (id) select 1
set transaction isolation level serializable
begin tran
select * from q
waitfor delay '0:0:20'
select * from q
commit tran
drop table q
во 2 сеансе
insert into q (id) select 2 --пока длится waitfor delay '0:0:20'
--
Sestrin
--- ifmail v.2.15dev5
* Origin: Sinor-NMTS (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
