Ну то есть пользователь выбрал билет, нажал кнопку, а ему и говорят: билет продан? Прекрасно, в чем тогда вообще смысл этого упражнения с «блокировками»?
в том что он это узнает сразу, а не после того как он ввел все данные и подтвердил
«как же показать пользователю карту незанятых мест?»
свободные места — не проданные билеты + на которых нет действительных блокировок
Правда, печально?
да я то же понял что вы описали именно эту проблему, но смотря в глаза реальности скорость продажи билетов не космическая.
у нас было несколько экспериментов по EF, разные комбинации, если использовать провайдеры от разного производителя, то результат не очень, с одним производителем дела на много лучше, но проблемы с запросами есть.
1. проверка есть ли блокировка
2. если нет, то ставиться блокировка и устанавливается тайм
3. если есть, то проверяется таймаут, если он просрочен, то сносим блокировку, переход к 2
Отмечаем где?
хороший вопрос, ну мы же где то должны сохранить, что такие то билеты проданы.
Вообще-то, это не уникальность, а дефолтное значение.
Согласен что AST (я походу подхватил, писать действительно проще чем expression tree) будет одно и то же, но вот провайдер может не суметь его обработать
при появлении новых запросов строиться новый билдер только для него, тестируется как запрос отрабатывает на разных репах, если на кком то что то плохо, то правки только для этой реализации. удобно кстате
Linq2Sql и EF, 2Sql издревна пошел, проект изначально на нем писался, к стати использовалось расширение контекста как хранилище набора скомпилированных запросов, вы приводили этот прием, только работа шла на прямую с контекстом.
Прекрасно. А если к этому моменту другой пользователь нажал «купить» с теми же местами?
одновременно внести записи в таблицу с одинаковыми ключами не возможно.
(а) что делать, если пользователь не оплатил?
я ж писал, дата (таймаут) по которой блокировка считается не действительной
(б) как в дальнейшем не продать билеты на эти места?
при сохранении отмечаем что билет продан.
Это обычная таблица в SQL, или что-то другое? Если да, то как, по-вашему, БД обеспечивает уникальность записей в индексе?
да,
ALTER TABLE [dbo].[Table] ADD CONSTRAINT [DF_Table_number] DEFAULT ((0)) FOR [number]
уникальность, правда это не ключ, просто вариантов несколько, как унифицировать запись
в таблице блокировок уникальность записи по составному ключу. lock escalation там не нужен, возможно вы не правильно поняли, таблица блокировок это НАШЕ творение.
1. проверка есть ли блокировка
2. если нет, то ставиться блокировка и устанавливается тайм
3. если есть, то проверяется таймаут, если он просрочен, то сносим блокировку, переход к 2
хороший вопрос, ну мы же где то должны сохранить, что такие то билеты проданы. да, не оттуда копипаст, промазал видимо блокирует таблицу на время записи.
я ж писал, дата (таймаут) по которой блокировка считается не действительной при сохранении отмечаем что билет продан. да,
ALTER TABLE [dbo].[Table] ADD CONSTRAINT [DF_Table_number] DEFAULT ((0)) FOR [number]уникальность, правда это не ключ, просто вариантов несколько, как унифицировать записьсохранили, сняли блокировку
в таблице блокировок уникальность записи по составному ключу. lock escalation там не нужен, возможно вы не правильно поняли, таблица блокировок это НАШЕ творение.