Насколько вы полагаетесь на транзакции базы данных?
Вы предпочитаете малые или большие объемы транзакций?
Вы предпочитаете обработку транзакций на стороне клиента (например, TransactionScope в .NET) транзакциям на стороне сервера или наоборот?
Как насчет вложенных транзакций?
Есть ли у вас какие-нибудь советы и рекомендации, связанные с транзакциями?
Какие-нибудь ошибки, с которыми вы столкнулись при работе с транзакцией?
Любые ответы приветствуются.
Я всегда оборачиваю транзакцию в оператор using.
using(IDbTransaction transaction )
{
// logic goes here.
transaction.Commit();
}
Как только транзакция выходит за рамки, она уничтожается. Если транзакция все еще активна, она откатывается. Такое поведение защищает вас от случайной блокировки базы данных. Даже если возникнет необработанное исключение, транзакция все равно откатится.
В моем коде я на самом деле опускаю явные откаты и полагаюсь на оператор using, который сделает всю работу за меня. Я только явно выполняю коммиты.
Я обнаружил, что этот шаблон значительно уменьшил проблемы с блокировкой записей.
Лично я, разрабатывая веб-сайт, основанный на высокой производительности трафика, по возможности избегаю транзакций с базой данных. Очевидно, что они необходимы, поэтому я использую ORM и объектные переменные уровня страницы, чтобы свести к минимуму количество вызовов на стороне сервера, которые я должен сделать.
Вложенные транзакции — отличный способ свести к минимуму ваши вызовы, я стараюсь двигаться в этом направлении всякий раз, когда могу, если это быстрые запросы, которые не вызывают блокировку. NHibernate был спасителем в этих случаях.
Я использую транзакции при каждой операции записи в базу данных.
Таким образом, есть довольно много небольших "транзакций", заключенных в более крупную транзакцию, и, по сути, во вложенном коде имеется большое число транзакций. Если есть какие-либо невыполненные дети, когда вы завершаете родителя, все откатывается.
Я предпочитаю обработку транзакций на стороне клиента, где это возможно. Если вы вынуждены выполнять sps или другие логические единицы работы на стороне сервера, транзакции на стороне сервера в порядке.
Ух ты! Много вопросов!
Еще год назад я на 100 % полагался на транзакции. Сейчас только 98%. В особых случаях веб-сайтов с высоким трафиком (таких как упомянутая Сара), а также данных с большим количеством разделов, что требует распределенных транзакций, может быть принята архитектура без транзакций. Теперь вам нужно закодировать ссылочную целостность в приложении.
Кроме того, мне нравится декларативно управлять транзакциями с помощью аннотаций (я специалист по Java) и аспектов. Это очень простой способ определения границ транзакций, который включает в себя функцию распространения транзакций.
Так же, как FYI... Вложенные транзакции могут быть опасными. Это просто увеличивает шансы попасть в тупик. Так что, хотя это хорошо и необходимо, то, как это реализовано, важно в ситуации с большим объемом.
Транзакции на стороне сервера, 35 000 транзакций в секунду, SQL Server: 10 уроков из 35 тыс. транзакций в секунду
Мы используем только транзакции на стороне сервера:
Другой:
Мы имеем дело с миллионами строк INSERT в день (некоторые из них группируются с помощью промежуточных таблиц), полный OLTP, никаких проблем. Но не 35k tps.
Это интересная ссылка для вложенных транзакций T-SQL: http://aleemkhan.wordpress.com/2006/07/21/t-sql-error-handling-pattern-for-nested-transactions-and-stored-procedures/
Как сказала Сара Чиппс, транзакция — это излишество для приложений с высоким трафиком. Поэтому мы должны избегать его, насколько это возможно. Другими словами, мы используем архитектуру BASE, а не ACID. Ebay — типичный случай. Распределенная транзакция вообще не используется в архитектуре Ebay. Но для эвентуальной согласованности вам придется проделать какой-то трюк самостоятельно .
