Использование транзакций с адаптерами данных ADO.NET

Сценарий: я хочу, чтобы несколько (от 2 до 20, вероятно) серверных приложений использовали одну базу данных с использованием ADO.NET. Я хочу, чтобы отдельные приложения могли владеть наборами записей в базе данных, хранить их в памяти (для скорости) в наборах данных, отвечать на запросы клиентов по данным, выполнять обновления и не позволять другим приложениям обновлять эти записи до тех пор, пока они не станут владельцем было отказано.

Я новичок в ADO.NET, но похоже, что это должно быть возможно с использованием транзакций с адаптерами данных (отключенный уровень ADO.NET).

Вопрос, часть 1: Это правильный способ попробовать и сделать это?

Вопрос, часть 2: Если это правильный способ, может ли кто-нибудь указать мне на какие-либо руководства или примеры такого подхода (на C #)?

Вопрос, часть 3: если я хочу иметь возможность владеть отдельными записями и выпускать их независимо, мне понадобится отдельная транзакция для каждой записи и, соответственно, отдельный DataAdapter и DataSet для хранения каждую запись, или есть лучший способ сделать это? Каждое приложение, вероятно, будет одновременно владеть тысячами записей.


c# transactions ado.net dataadapter
person Ergwun    schedule 17.06.2010    source источник

Ответы (2)


arrow_upward
1
arrow_downward

  • Как долго вы думали о том, чтобы транзакция оставалась открытой?
  • Сколько одновременных пользователей вы собираетесь поддерживать?

Это два вопроса, которые вам нужно задать себе. Если ответ на первый вопрос - «долго», а на второй - «много», то этот подход, вероятно, столкнется с проблемами.

Итак, мой ответ на первый вопрос: нет, вероятно, это неправильный подход.

Если вы воспользуетесь подходом с транзакционной блокировкой, вы ограничите масштабируемость и время отклика. Вы также можете столкнуться с ошибками базы данных. например SQL Server (при условии, что вы используете SQL Server) может быть очень жадным с блокировками и может заблокировать больше ресурсов, чем вы запрашиваете / ожидаете. Приложение может запросить некоторые блокировки на уровне строк, чтобы заблокировать записи, которыми оно «владеет», однако SQL Server может повысить уровень блокировки этих строк до блокировки таблицы. Это приведет к блокировке и может привести к тайм-аутам или, возможно, тупикам.

Я думаю, что лучший способ удовлетворить требования, как вы их заявили, - это написать систему управления блокировками / контроля записей. Мартин Фаулер называет это пессимистической блокировкой офлайн.

ОБНОВЛЕНИЕ

Если вы используете SQL Server 2008, вы можете установить поведение эскалации блокировки на уровне таблицы:

ALTER TABLE T1 SET (LOCK_ESCALATION = DISABLE);

Это отключит эскалацию блокировки в «большинстве» ситуаций и может вам помочь.

person Randy supports Monica    schedule 18.06.2010
comment
Да, я думал о том, чтобы транзакции оставались открытыми в течение длительного времени. Все приложения, обращающиеся к базе данных, находятся на стороне сервера. Было бы лишь небольшое количество этих приложений, обслуживающих до тысяч клиентов. Право собственности на записи будет редко переноситься между серверными приложениями. Это будет только в тех случаях, когда несколько серверных приложений будут пытаться получить доступ к одним и тем же записям одновременно. В этих условиях я надеялся, что смогу использовать транзакции для достижения пессимистичного параллелизма. Однако ваше предупреждение о жадной блокировке SQL-сервера звучит как серьезная проблема. - person Ergwun; 21.06.2010
comment
@Ergwun: вы используете SQL Server 2008? - person Randy supports Monica; 21.06.2010
comment
Да, на данный момент, но я надеюсь, что мои приложения останутся независимыми от поставщика данных. Спасибо. - person Ergwun; 21.06.2010
comment
+1 Спасибо за ссылку Pessimistic Offline Lock и совет по эскалации блокировки. - person Ergwun; 23.06.2010

arrow_upward
0
arrow_downward

Вам действительно нужен контроль параллелизма, а также поддержка транзакций.

Transaction появляется только тогда, когда вы выполняете несколько операций с базой данных. Как только соединение будет разорвано, транзакция больше не применима.

concurrency позволяет работать с несколькими обновлениями одних и тех же данных. Если два или более клиентов содержат один и тот же набор данных, и одному из них необходимо прочитать / записать данные после того, как другой клиент обновит их, параллелизм позволит вам решить, какой набор обновлений сохранить, а какой игнорировать. Упоминание концепции параллелизма выходит за рамки данной статьи. Дополнительные сведения см. В этой статье.

person this. __curious_geek    schedule 18.06.2010
comment
Я надеялся использовать длинные транзакции для достижения пессимистичного параллелизма. Поскольку все приложения являются серверными, я надеялся, что это будет работоспособное решение. - person Ergwun; 21.06.2010
comment
В этом случае посмотрите на TransactionScope. - person this. __curious_geek; 21.06.2010