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

BlazkowiczMaxNevermindИногда сталкиваюсь с вопросом определения уровня изоляции на собеседованиях
Вопрос по базам данных в форуме по Java?
Вопросы на Java собеседовании, хотелось бы услышать как именно они решают подобные задачи да решают ли в принципе, может я вопрос не правильно понимаю.

BlazkowiczMaxNevermindкак допустим уровень изоляции выбрать для реализации метода апдейта баланса, опыта подобной работы у меня нет, поэтому не знаю током что отвечать.
Наверное это намек на serializable, когда транзакции выстраиваются в очередь, так сводиться к минимуму конкуренции при чтении-записи баланса.
http://www.postgresql.org/docs/9.1/static/transaction-iso.html вот здесь по-моему написано например, что Repeatable Read вроде для этой операции подходит, там прямо этот пример, нет?

BlazkowiczMaxNevermindВ проекте со сложной бизнес логикой может быть куча запросов различных вариаций

Запросы в базах данных. А сложную логику лучше выносить в Java а ещё более сложную в DSL. Только как сложность связана с транзакциями?
Сложная логика - сложные запросы - ломай голову над каждым запросом, пытаясь выяснить поломается ли что-нибудь если сделать так или так.

BlazkowiczMaxNevermindошибка выбора уровня может привести к неправильным расчетам

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

BlazkowiczMaxNevermindнад этим каждый раз надо ломать голову? Или используются какие-то простые принципы в зависимости от СУБД с которой идет работа, типа если это рид онли, то такой-то, если апдейт одного поля с отбором по ключу то такой-то, если для всего более сложного сериалайзабл?
Обычно используется дефолтный Read Committed, до тех пор пока требования и их решения не приводят к выводу что нужен другой уровень. Вот у нас 10 запросов, в каждом несколько таблиц, некотороые просто читают, некоторые читают и апдейдят и т.п., что значит здесь "...до тех пор пока.." каждый запрос отдельная история, нет?

DEVcoach MaxNevermind ,
Здесь нужно просто понимать, какие непредвиденные эффекты могут возникать при том или ином уровне изоляции. И решать, готовы ли вы с ними жить. Например, поставили вы READ_COMMITTED. А нормально будет, если вы в рамках одной транзакции дважды попросите выдать сотрудников отдела "Закупки", и вам во второй раз вернется меньше людей, чем при первом вызове? Нет, тогда подкручивайте изоляцию до REPEATABLE_READ. И т.д.. Это все следует исключительно из требований к логике.
Вы просто изложили какие возможны проблемы при использовании READ_COMMITTED, при чем достаточно абстрактно.
Вы, например можете сказать с какой проблемой мы можете столкнуться написав подобное на уровне Read Committed:


Ответ здесь - http://www.postgresql.org/docs/9.1/static/transaction-iso.html
При чем, из этой общей теории о уровнях изоляции, то есть того что вы написали, это нельзя понять. И как вы будете тогда принимать решение о уровне изоляции если вы этого не знаете? Я это к тому, что выглядит так что, нужно глубоко вникать в специфику работы конкретной СУБД с который работаете и после этого ломать голову над каждым запросом.