Такая ситуация: есть база данных на Oracle. Есть приложение к ней на .Net, причем доступ к данным через Entity Framework 1.0. Когда с базой работают несколько экземпляров программ, то получается такая ситуация: один скачал данные, другой скачал данные, один удалил строку, другой собрался удалить ту же строку — получил облом. С обновлением еще круче — изменения второго попросту перезаписывают изменения первого.

Поэтому желательно блокировать данные при первом чтении и не давать остальным читать их, пока первый их не закоммитит обратно в базу.

Как это сделать средствами Oracle (какими)? И как провести это через Entity Framework, ведь он сам генерирует SQL?

dmitry_npi wrote:

> Поэтому желательно блокировать данные при первом чтении и не давать
> остальным читать их, пока первый их не закоммитит обратно в базу.

Тебе это не нужно делать. Правда, ты ещё пока об этом не знаешь.
Хотя нет, вот уже и узнал.

читай об оптимистичной стратегии блокировок.
блокировать можно конструкцией select ... for update, но это делать лишь в том случае если оптимистичная стратегия никак не годиться.

Здравствуйте, MasterZiv, Вы писали:

MZ>Правда, ты ещё пока об этом не знаешь.
Я догадывался. Как я понимаю, при совместной работе над одними данными существует принципиально два подхода: либо взаимная блокировка, либо слияние и разрешение конфликтов.

MZ>Хотя нет, вот уже и узнал.
И так как слияние реализовывать сложнее (а главное все-таки — целостность данных), то я решил остановиться на блокировке.

MZ>Тебе это не нужно делать.
С чего ты так решил? А как тогда нужно?

Здравствуйте, Аноним, Вы писали:

А>читай об оптимистичной стратегии блокировок.
А>блокировать можно конструкцией select ... for update, но это делать лишь в том случае если оптимистичная стратегия никак не годиться.

Насколько я понимаю, оптимистичная стратегия — это "мы надеемся что конфликтов не возникнет, а если возникнут, то... упс! исключение!" и далее разбираемся как можем. Поправьте если я ошибаюсь.

Ну и вопрос по существу — а как заставить Entity Framework выдавать в базу "select ... for update"?

_>Насколько я понимаю, оптимистичная стратегия — это "мы надеемся что конфликтов не возникнет, а если возникнут, то... упс! исключение!" и далее разбираемся как можем. Поправьте если я ошибаюсь.

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

_>Ну и вопрос по существу — а как заставить Entity Framework выдавать в базу "select ... for update"?

слава богу понятия не имею

dmitry_npi wrote:

> Насколько я понимаю, оптимистичная стратегия — это "мы надеемся что
> конфликтов не возникнет, а если возникнут, то... упс! исключение!" и
> далее разбираемся как можем. Поправьте если я ошибаюсь.

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

В качестве маркеров могут выступать:
-- специальные поля типа timestamp
-- специальные поля типа datetime
-- просто все или только изменяемые поля данных.

В любом случае в БД должно быть обеспечено обязательное изменение
маркеров при любом изменении данных.

>
> Ну и вопрос по существу — а как заставить Entity Framework выдавать в
> базу "select ... for update"?

повысить уровень изоляции твоей транзакции.

dmitry_npi wrote:

> MZ>Тебе это не нужно делать.
> С чего ты так решил?

Я просто знаю. Ты думаешь, ты первый, кто задаёт такие глупые вопросы ?

А как тогда нужно?

Повышать уровень изоляции транзакций. Просто ставишь уровень выше, и всё.

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

Хотя тут конечно всё зависит от задачи, возможно, тебе и правда
данные нужно блокировать. Ну, тогда повышай уровень изоляции.

Здравствуйте, dmitry_npi, Вы писали:

<skip>

Не знаю, как конкретно реализовать в EF, но старый-добрый Oracle Forms работает так: если пользователь начинает редактировать запись, на нее накладывается примерно такая блокировка:

SELECT 1 FROM your_table WHERE rowid = :edit_rowid FOR UPDATE
-- а лучше даже так (так приложение сразу исключение выкинет, если уже кто-то заблокировал запись):
SELECT 1 FROM your_table WHERE rowid = :edit_rowid FOR UPDATE NOWAIT

Дешево и сердито. Получается, что если кто-то начал редактировать, то другой пользователь сделать это уже не сможет.

Здравствуйте, dmitry_npi, Вы писали:

_>Поэтому желательно блокировать данные при первом чтении и не давать остальным читать их, пока первый их не закоммитит обратно в базу.

Почему желательно так жестко? Это требование от бизнес-логики или просто первое, что пришло в голову?
Прикинь, в скольки процентах случаев за чтением данных следует их изменение?

Про оптимистическую и пессимистическую стратегию блокирования почитай для начала Вики.

Здравствуйте, dya-victor, Вы писали:

DV>старый-добрый Oracle Forms работает так: если пользователь начинает редактировать запись,
которую кто-то изменил (и закоммитил) после её селекта из базы выдаёт сообщение "Запись изменена другим пользователем..."

ЗЫ Читая такие темы убеждаюсь, что "старый-добрый Oracle Forms" при всей убогости интерфейса лучше всех новых средств работы с базой.

Здравствуйте, wildwind, Вы писали:

W>Почему желательно так жестко? Это требование от бизнес-логики или просто первое, что пришло в голову?
W>Прикинь, в скольки процентах случаев за чтением данных следует их изменение?
Конечно, последует. Но этого допускать нельзя. По идее, над фрагментом данных должен работать один пользователь. Каждый над своим. Если двое работают над одним — это нарушение рабочего процесса.

Здравствуйте, dmitry_npi, Вы писали:

_>Здравствуйте, wildwind, Вы писали:

W>>Почему желательно так жестко? Это требование от бизнес-логики или просто первое, что пришло в голову?
W>>Прикинь, в скольки процентах случаев за чтением данных следует их изменение?
_>Конечно, последует. Но этого допускать нельзя. По идее, над фрагментом данных должен работать один пользователь. Каждый над своим. Если двое работают над одним — это нарушение рабочего процесса.

То есть нет такого сценария "просто посмотреть на данные", а есть только "посмотреть и тут же изменить"? Очень странное приложение, до сих пор не встречал таких, ну да ладно.

В этом случае можно блокировать строку таблицы с помощью select ... for update nowait. Если получили исключение "resource busy", значит строка уже заблокирована.
Насчет Entity Framework не подскажу, но возможность выполнить произвольный SQL там быть должна.

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