Сохранение темы «Выбрать» Linq Queries?

Question

Я понимаю, как редактирование строк может вызвать проблемы параллелизма, но проблемы параллелизма, вызванные выбором строк, я не понимаю.

Если запрос выбирает данные из базы данных, как может возникнуть проблема параллелизма?Если в данных, которые я выбрал, произойдут изменения, все будет взорвано?

В любом случае, если есть проблема с параллелизмом, вызванная запросом select, как лучше всего справитьсяЭто?Это то, что я имею в виду, но я бы не удивился, если бы это было неправильно.

try
{
    var SelectQuery = 
    from a DB.Table
    where a.Value == 1
    select new {Result = a};
}
catch 
{
    //retry query??
}

Answer 1

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

Более важный момент, который стоит обратить внимание на ваш пример, заключается в том, что код, который вы помещаете в блок try / catch, на самом деле не выполняет никаких запросов. Он просто строит дерево выражений. SQL-запрос на самом деле не будет выполняться, пока вы не сделаете что-то, что вызовет оценку этого дерева выражений, например, вызовет SelectQuery.ToList().

Имейте в виду, что есть ряд вещей, которые могут "пойти не так", когда вы пытаетесь запросить базу данных. Возможно, кто-то выполняет массовые обновления данных, которые вы пытаетесь выбрать, и время вашего соединения истекает до завершения запроса. Может быть, кабель разбит, или случайный бит космического излучения заставляет его где-то потеряться. С другой стороны, возможно, в вашем запросе что-то не так, или, возможно, используемый вами контекст базы данных не синхронизирован со схемой базы данных. Некоторые из вещей, которые могут пойти не так, являются только периодическими, и вы можете просто повторить попытку, как подсказывает ваш вопрос. Другие вещи могут быть более продолжительными и будут повторяться. В этих последних случаях, если вы попытаетесь повторить свое действие до тех пор, пока не перестанете получать ошибки, ваш поток может зависать там очень долго.

Поэтому, когда вы решаете, как решать проблемы с подключением к базе данных, обратите внимание на частоту возникновения каждого типа проблемы. Я видел код, который пытается выполнить транзакцию три раза, прежде чем отказаться, , как это . Но когда дело доходит до повседневных запросов, такого рода вещи случаются настолько редко, что лично я бы позволил исключению просочиться туда, где пользовательский интерфейс может сказать: «Произошла непредвиденная ошибка. Пожалуйста, попробуйте еще раз. Если проблема сохраняется, свяжитесь с ваш администратор. " Или что-то в этом роде.

Answer 2

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

Простейший пример - когда объект, с которого выполняется чтение, имеет сходство с потоком, а чтение происходит из другого потока. Это может привести к гонке, поскольку к данным обращаются ненадлежащим образом.

Лучший способ справиться с проблемой параллелизма - просто избежать ее. Если у вас есть 2 потока, играющих с одним и тем же фрагментом данных, используя блокировку для сериализации доступа к данным, , вероятно, , лучший подход. Хотя для окончательного решения требуется немного больше деталей.

Можете ли вы объяснить, что здесь происходит и почему происходит гонка? Другие потоки изменяют этот объект, пока вы читаете его?