У меня есть рабочая очередь в SQL, управляемая некоторыми службами, которые считывают записи для обработки READPAST запросами.
Недавно я добавил пользовательский интерфейс для проверки статуса очереди, который использует READ UNCOMMITTED запросы NHibernate на C #. Совершенно не критично, что они вернули мне правильные числа, просто указание на то, как далеко продвинулась обработка.
/* called from a foreach (I know... I could get them all at once with SQL) */
IQuery query = Persistence.CreateQuery(
"select count(qi) from QueueItem qi where qi.Job = :job");
query.SetEntity("job", thisJob);
using(Persistence.ReadUncommitted())
{
return (long)query.UniqueResult();
}
Проблема в том, что эти статусные запросы начали вызывать тайм-ауты. Иногда они терпят неудачу; иногда они приводят к сбою операций с очередью.
В основной документации MSDN говорится, что блокировка все еще может быть заблокирована, если я изменю схему. , а я нет.
С другой стороны, Марсель ван дер Холст, который, очевидно, работает в группе Microsoft SQL Server, говорит об этом (вопрос задает Майкл не я):
READ UNCOMMITTEDтранзакции не будут блокировать базу данных, но им все равно придется читать страницы базы данных для чтения фактических данных. Если другие транзакции записывают эти страницы в одно и то же время, это может быть некоторая блокировка между ними. Внутри движка мы не разрешаем никаким транзакциям читать страницу во время записи (мы используем защелки, чтобы гарантировать это). Если во время обработки больших запросов выполняется много транзакций, большое чтение все равно может быть заблокировано.
Я что-то не так делаю? Что мне нужно изменить, чтобы отключить блокировку?
Схема
create table QueueItem(
ID int identity(1,1) not null,
JobID int not null,
PersonID int not null,
DateProcessed datetime null,
Error varchar(max) null,
constraint [PK_QueueItem] primary key nonclustered (ID)
)
alter table QueueItem
add constraint [FK_QueueItemsToJobs] foreign key (JobID)
references Job (ID)
Некластеризованные индексы:
JobID, DateProcessed, PersonID, ID (Non-Unique, Non-Clustered)
DateProcessed, JobID, PersonID (Non-Unique, Non-Clustered)
JobID, ID (Unique, Non-Clustered)
JobID, PersonID, ID (Unique, Non-Clustered)
PersonID, JobID, ID, DateProcessed (Unique, Non-Clustered)
ID (Unique, Non-Clustered)
На практике
Я уменьшил количество чтений, потому что это не замедлит работу, но мне все еще любопытно, почему может быть блокировка с READ UNCOMMITTED.
