Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Транзакции в многопользовательском приложении  [new]
harisma
Member

Откуда:
Сообщений: 243
Есть у нас трехуровневое клиент-серверное приложение (тонкий клиент-толстый сервер-сервер баз данных).
Некоторые операции я охватываю транзакцией. Как правило это такие операции, во время которых происходит множество действий в разных таблицах в базе данных. Когда работает один человек, то все в порядке. Но когда начинает работать несколько пользователей одновременно, выполняя вот такие подобные операции, то начинаются траблы, о чем система сообщает в виде деадлоков, сообщений о нехватке ресурсов и т. д.
Специфика охватываемых транзакцией операций такова, что они должны или полностью выполниться, или полностью откатиться. Частичное выполнение всего набора действий операции недопустимо.
Как мне организовать корректную работу этих транзакций в многопользовательской среде? Может есть какая альтернатива?
9 окт 12, 13:52    [13290238]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в многопользовательском приложении  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37202
Т.е. я правильно понял, что транзакция открывается как только человек начал работать, и закрывается когда он закончил работать?
9 окт 12, 14:19    [13290476]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в многопользовательском приложении  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 5114
и уровень изоляции у ваших транзакций какой?
9 окт 12, 14:27    [13290552]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в многопользовательском приложении  [new]
harisma
Member

Откуда:
Сообщений: 243
Гавриленко Сергей Алексеевич,

Нет. Только при начале выполнения некоторой многошаговой операции.
Ну, как бы вам попроще объяснить...
В нашем программном продукте есть несколько типов объектов, таких как "Документы", "Журналы", "Аккумуляторы", "Справочники" и. т. д.
Журналы хранят в себе списки документов определенного типа и состояние этих документов
Документ - это аналог товарно-транспортной накладной в торговле.
Аккумулятор - объект, в котором хранится накопительная информация об остатках материальных ценностей на складах (к примеру) на конкретную дату.
Справочник - список материальных ценностей в системе (например наименования и параметры товаров на каком-нибудь складе)
Многошаговой операцией я называю фиксацию и расфиксацию документа. В данном случае должно измениться состояние документа в таблице документов, измениться состояние этого документа в таблице журнала, где этот документ отображается, Добавиться или удалиться набор записей в аккумулятор (ы), возможно, создаться (удалиться) один или несколько вспомогательных документов и т. д.
Ну, вот как то так.
9 окт 12, 14:36    [13290649]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в многопользовательском приложении  [new]
harisma
Member

Откуда:
Сообщений: 243
Дедушка,

Поскольку программный продукт должен работать также и на SQL 2000, то соответственно использую уровень изоляции по умолчанию: READ COMMITTED если не ошибаюсь, потому как не использую комманду SET TRANSACTION ISOLATION LEVEL ...
9 окт 12, 14:46    [13290729]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в многопользовательском приложении  [new]
aleks2
Guest
harisma
Специфика охватываемых транзакцией операций такова, что они должны или полностью выполниться, или полностью откатиться. Частичное выполнение всего набора действий операции недопустимо.
Как мне организовать корректную работу этих транзакций в многопользовательской среде? Может есть какая альтернатива?

1. В блокировочниках: чем меньше времени вы находитесь в транзакции - тем реже ваши пользователи вспоминают о вашем существовании и тем меньше выносят вам мозг.
2. Столбовой путь: подготовили данные для транзакции во временной таблице, посчитали все что можно, например. В транзакции одним-двумя апдэйтами захерачили данные в базу. Закрыли транзакцию.
9 окт 12, 15:22    [13291034]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в многопользовательском приложении  [new]
harisma
Member

Откуда:
Сообщений: 243
aleks2
harisma
Специфика охватываемых транзакцией операций такова, что они должны или полностью выполниться, или полностью откатиться. Частичное выполнение всего набора действий операции недопустимо.
Как мне организовать корректную работу этих транзакций в многопользовательской среде? Может есть какая альтернатива?

1. В блокировочниках: чем меньше времени вы находитесь в транзакции - тем реже ваши пользователи вспоминают о вашем существовании и тем меньше выносят вам мозг.
2. Столбовой путь: подготовили данные для транзакции во временной таблице, посчитали все что можно, например. В транзакции одним-двумя апдэйтами захерачили данные в базу. Закрыли транзакцию.


п.1 - это понятно, что транзакция должна выполняться минимальный промежуток времени. Так и делаем.
п.2 - у нас на изменяемых таблицах еще навешаны триггеры, которые выполняются также в контексте этой транзакции. Кроме того, еще есть конфигурационный код приложения (по аналогии с программой 1С Бухгалтерия), результат работы которого также охватывается транзакцией. Вот в результате и получается непредсказуемый заранее набор операций. Таким образом собрать все нужное в какой-то временной таблице скорее всего не выйдет :(

Какие еще будут варианты?

Немного выше спрашивали меня про уровень изоляции. Как думаете, если перед открытием этой нашей транзакции, поменять уровень изоляции на READ UNCOMMITTED, а после завершения вновь вернуть на READ COMMITTED, может получится из этого какая-то польза в плане решения вопроса деадлоков, задержек и т. д.?
10 окт 12, 11:11    [13294334]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в многопользовательском приложении  [new]
invm
Member

Откуда: Москва
Сообщений: 9687
harisma
Немного выше спрашивали меня про уровень изоляции. Как думаете, если перед открытием этой нашей транзакции, поменять уровень изоляции на READ UNCOMMITTED, а после завершения вновь вернуть на READ COMMITTED, может получится из этого какая-то польза в плане решения вопроса деадлоков, задержек и т. д.?
В плане решения вопроса деадлоков, задержек и т.д. и т.п., поможет выявление и устранение причин их возникновения, а не бездумное жонглирование TIL'ом без понимания того, к чему это может привести.
10 окт 12, 11:20    [13294399]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в многопользовательском приложении  [new]
Aleksey V.P.
Member

Откуда: Москва
Сообщений: 575
harisma,

Вы в select запросах хоть используете with (NoLock) ?
10 окт 12, 11:25    [13294427]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в многопользовательском приложении  [new]
AnaceH
Member

Откуда:
Сообщений: 109
Aleksey V.P.
harisma,

Вы в select запросах хоть используете with (NoLock) ?

Ну сейчас вы научите.
10 окт 12, 11:28    [13294450]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в многопользовательском приложении  [new]
Aleksey V.P.
Member

Откуда: Москва
Сообщений: 575
AnaceH
Aleksey V.P.
harisma,

Вы в select запросах хоть используете with (NoLock) ?

Ну сейчас вы научите.


Вряд ли, на сиквеле мы используем Read Uncommited + NoLock в select запросах, что бы минимизировать кол-во блокировок.
10 окт 12, 11:37    [13294519]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в многопользовательском приложении  [new]
invm
Member

Откуда: Москва
Сообщений: 9687
Aleksey V.P.
Вряд ли, на сиквеле мы используем Read Uncommited + NoLock в select запросах, что бы минимизировать кол-во блокировок.
Что характеризует либо ваше неумение с ним работать, либо допустимость для ваших задач чтения грязных данных.
10 окт 12, 11:42    [13294572]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в многопользовательском приложении  [new]
Aleksey V.P.
Member

Откуда: Москва
Сообщений: 575
invm
Aleksey V.P.
Вряд ли, на сиквеле мы используем Read Uncommited + NoLock в select запросах, что бы минимизировать кол-во блокировок.
Что характеризует либо ваше неумение с ним работать, либо допустимость для ваших задач чтения грязных данных.


Второе.
10 окт 12, 11:44    [13294593]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в многопользовательском приложении  [new]
invm
Member

Откуда: Москва
Сообщений: 9687
Aleksey V.P.
invm
пропущено...
Что характеризует либо ваше неумение с ним работать, либо допустимость для ваших задач чтения грязных данных.


Второе.
И почему вы решили, что у ТС'а это тоже допустимо?
Впрочем, каждый сам себе граблеукладчик...
10 окт 12, 11:49    [13294638]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в многопользовательском приложении  [new]
Aleksey V.P.
Member

Откуда: Москва
Сообщений: 575
invm
Aleksey V.P.
пропущено...


Второе.
И почему вы решили, что у ТС'а это тоже допустимо?
Впрочем, каждый сам себе граблеукладчик...


Потому, что ТС не указал, что это недопустимо.
10 окт 12, 11:52    [13294664]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в многопользовательском приложении  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 5114
harisma

из ваших описаний системы понятно только одно без влезания в вашу архитектуру и контекст с головой советовать смысла нет.
посему имхо,
- наймите хорошего сиквел архитектора/админа (хоть по контракту) на аудит и тюнинг
- будьте готовы к рефакторингу архитектуры
- найдите конкретные проблемные места/процессы
10 окт 12, 11:54    [13294678]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в многопользовательском приложении  [new]
invm
Member

Откуда: Москва
Сообщений: 9687
Любителям NOLOCK посвящается -- The Side Effect of NOLOCK
10 окт 12, 12:16    [13294850]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в многопользовательском приложении  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31823
harisma
п.1 - это понятно, что транзакция должна выполняться минимальный промежуток времени. Так и делаем.
п.2 - у нас на изменяемых таблицах еще навешаны триггеры, которые выполняются также в контексте этой транзакции. Кроме того, еще есть конфигурационный код приложения (по аналогии с программой 1С Бухгалтерия), результат работы которого также охватывается транзакцией. Вот в результате и получается непредсказуемый заранее набор операций. Таким образом собрать все нужное в какой-то временной таблице скорее всего не выйдет :(

Какие еще будут варианты?
Да какие тут варианты? Только правильно писать. "непредсказуемый заранее набор операций" - это как то неправильно, что то в архитектуре не так.

"транзакция должна выполняться минимальный промежуток времени" - это значит, что все изменения в рамках одной транзакции нужно делать в одной ХП (например), в которой ещё можно что то вызвать. Без ХП тоже можно, но как минимум вы добавляете к времени транзакций обмен между сервером и приложением. И я так подозреваю, что вы ещё добавляете и время вычислений внутри клиента, всякие создания объектов и т.д. - наверняка такой ерундой никто не заморачивался :-)

Триггеры нужно применять только для контроля и для логирования.
Логически отдельные операции тоже не надо делать в этой же транзакции - зачем объединять бизнес-действие и изменение конфигурации, вы вообще накапливаете любые изменения в клиенте, а потом их скопом выполняете в одной транзакции?
harisma
Как думаете, если перед открытием этой нашей транзакции, поменять уровень изоляции на READ UNCOMMITTED, а после завершения вновь вернуть на READ COMMITTED, может получится из этого какая-то польза в плане решения вопроса деадлоков, задержек и т. д.?
Можно, но так же можно и не делать общую транзакцию. Это вообще напоминает поиск "волшебной кнопки". Транзакции и блокировки - это определяемая вами бизнес-логика, а не бага сервера, это нельзя пофиксить какой то настройкой.
10 окт 12, 12:51    [13295179]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить