powered by simpleCommunicator - 2.0.50     © 2025 Programmizd 02
Форумы / ADO.NET, LINQ, Entity Framework, NHibernate, DAL, ORM [игнор отключен] [закрыт для гостей] / ADO . NET Concurrency
4 сообщений из 4, страница 1 из 1
ADO . NET Concurrency
    #38633639
_andrews_.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В основном описание борьбы с параллелизмом ведется на примере редактирования уже загруженых в кэш данных внутри DataSet.
А что делать, если одна и та же запись будет обновляться через команду

Код: c#
1.
2.
3.
4.
5.
6.
            using (var connection = new FbConnection(aConnectionString))
            {
                var cmd = new FbCommand(aSQL, connection);
                connection.Open();
                return cmd.ExecuteNonQuery();
            }



Или, что более вероятно, если записи из разных таблиц коммитятся в одной "длинной" транзакции, и эта запись произойдет одновременно из нескольких подключений.

В этом случае как обрабатывать параллелизм? И возникнут ли вообще какие-то события, говорящие об ошибке параллелизма.
Планирую использовать Оптимистичный.
...
Рейтинг: 0 / 0
ADO . NET Concurrency
    #38633719
petalvik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_andrews_.,

ExecuteNonQuery вернёт количество изменённых записей в БД. Допустим, в нашем запросе должна была поменяться ровно одна запись. Если вернулось 1 - всё нормально. Если 0 - значит в другом подключении значение было уже изменено. Классическое решение в этом случае следующее: считываем данные заново, показываем пользователю, и он решает, нужно ли их менять ещё раз.

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

В-общем, вся логика в этом случае строится на возвращаемом значении количества изменённых записей.
...
Рейтинг: 0 / 0
ADO . NET Concurrency
    #38635297
_andrews_.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
petalvik,

все вышеописанное касается ведь работы с DataSet?
И это логично. Данные выгружены из базы в состоянии 1. Потом кто-то изменяет эти данные, и они уже находятся в состоянии 2.
И теперь при попытке перевести данные из состояния 1 в состояние 3 - мы получим ошибку параллелизма.

Но если я выполняю обновление одной записи через команду, то какая ошибка может возникнуть здесь?
Или речь идет о том, что есть вероятность что ровно в ту же секунду, или даже в ту же милисекунду кто-то обновляет ту же запись? Это фантастический вариант мне кажется.

по-моему при использовании подключенного стиля, при выполнении скриптов через команды возможен только Exception при блокировке транзакций:

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
        private static void ExecuteNonQuery(FbCommand[] aCommand)
        {            
                using (var connection_ = new FbConnection(сonnectionString))
                {
                    connection_.Open();
                    var trans = connection_.BeginTransaction();
                    try
                    {
                        foreach (var command in aCommand)
                        {
                            command.Connection = connection_;
                            command.Transaction = trans;
                        }
                        trans.Commit();
                    }
                    catch (FbException e)
                    {
                        // Либо повторить обновление данных заново, либо откат транзакции
                        trans.Rollback();
                    }
                }
        }



Или нет?
...
Рейтинг: 0 / 0
ADO . NET Concurrency
    #38636053
petalvik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_andrews_.все вышеописанное касается ведь работы с DataSet?
Нет, почему же. Это справедливо и для подключенного уровня.
Правда, я решил, что делается так: подключаемся к БД, выполняем запрос, работаем с полученными данными (они сохранены не в датасете, а в локальных переменных), снова подключаемся, обновляем данные.
В этом случае данные вполне могли быть изменены кем-то другим за это время.

_andrews_.Но если я выполняю обновление одной записи через команду, то какая ошибка может возникнуть здесь?
Смотря какая команда. Если это просто update без проверки предыдущего значения, то он всегда выполнится. Тогда можно не проверять возвращённое значение.

_andrews_.по-моему при использовании подключенного стиля, при выполнении скриптов через команды возможен только Exception при блокировке транзакций
Дэвид Сеппа, автор популярной книги по ADO.NET, крайне не рекомендует выполнять длительную работу, удерживая блокировку транзакции. Лучше считать данные, освободить БД для других подключений, а потом, при следующем подключении, разруливать возможные проблемы.
...
Рейтинг: 0 / 0
4 сообщений из 4, страница 1 из 1
Форумы / ADO.NET, LINQ, Entity Framework, NHibernate, DAL, ORM [игнор отключен] [закрыт для гостей] / ADO . NET Concurrency
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]