|
ADO . NET Concurrency
|
|||
---|---|---|---|
#18+
В основном описание борьбы с параллелизмом ведется на примере редактирования уже загруженых в кэш данных внутри DataSet. А что делать, если одна и та же запись будет обновляться через команду Код: c# 1. 2. 3. 4. 5. 6.
Или, что более вероятно, если записи из разных таблиц коммитятся в одной "длинной" транзакции, и эта запись произойдет одновременно из нескольких подключений. В этом случае как обрабатывать параллелизм? И возникнут ли вообще какие-то события, говорящие об ошибке параллелизма. Планирую использовать Оптимистичный. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 18:09 |
|
ADO . NET Concurrency
|
|||
---|---|---|---|
#18+
_andrews_., ExecuteNonQuery вернёт количество изменённых записей в БД. Допустим, в нашем запросе должна была поменяться ровно одна запись. Если вернулось 1 - всё нормально. Если 0 - значит в другом подключении значение было уже изменено. Классическое решение в этом случае следующее: считываем данные заново, показываем пользователю, и он решает, нужно ли их менять ещё раз. Естественно, запрос на изменение в этом случае должен быть составлен соответствующим образом. В условии WHERE проверяем не только первичный ключ (что обязательно), но и проверяем, равно ли значение меняемого столбца прежнему. В-общем, вся логика в этом случае строится на возвращаемом значении количества изменённых записей. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 19:37 |
|
ADO . NET Concurrency
|
|||
---|---|---|---|
#18+
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.
Или нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2014, 10:56 |
|
ADO . NET Concurrency
|
|||
---|---|---|---|
#18+
_andrews_.все вышеописанное касается ведь работы с DataSet? Нет, почему же. Это справедливо и для подключенного уровня. Правда, я решил, что делается так: подключаемся к БД, выполняем запрос, работаем с полученными данными (они сохранены не в датасете, а в локальных переменных), снова подключаемся, обновляем данные. В этом случае данные вполне могли быть изменены кем-то другим за это время. _andrews_.Но если я выполняю обновление одной записи через команду, то какая ошибка может возникнуть здесь? Смотря какая команда. Если это просто update без проверки предыдущего значения, то он всегда выполнится. Тогда можно не проверять возвращённое значение. _andrews_.по-моему при использовании подключенного стиля, при выполнении скриптов через команды возможен только Exception при блокировке транзакций Дэвид Сеппа, автор популярной книги по ADO.NET, крайне не рекомендует выполнять длительную работу, удерживая блокировку транзакции. Лучше считать данные, освободить БД для других подключений, а потом, при следующем подключении, разруливать возможные проблемы. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2014, 22:11 |
|
|
start [/forum/topic.php?fid=17&fpage=20&tid=1349783]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
37ms |
get topic data: |
13ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
others: | 241ms |
total: | 365ms |
0 / 0 |