Leonid Kudryavtsev, я-бы вместе с SELECT рассмотрел изоляцию. Это способность
видеть или не видеть dirty, фантомы и прочие штуки которые идут еще с эпохи
файловых БД.

Oracle по дефолту всегда включает READ COMMITED. Другие DBMS - не знаю.

Кроме того есть наверное архитектурный gap между уровнями изоляций JDBC
и практическим количеством этих изоляций которые реально поддерживаются
в текущей DBMS.

Грубо говоря они могут не маппится 1:1.

Вообще рассматривать сферический SQL еще можно. В рамках ASNI стандартов.

Но как рассматривать сферическую DBMS и ее режимы изоляции - я не знаю.
Скорее всего - никак.

Leonid Kudryavtsevmaytonя-бы .... рассмотрел изоляцию. Это способность видеть или не видеть....

Грубо говоря они могут не маппится 1:1

Говорю на бытовом языке, за точностью терминов не гонюсь. Мне кажется, есть два разных механизма СУБД

1. обеспечение версионности = "изоляция"
2. обеспечение целостности при записи

Теоретически "транзакция" это и то и другое ("и можно без хлеба" ( C ), желательно в режиме serialized), практически - две разных механизма, которые не всегда маппятся 1:1

Когда есть UPDATE/DELETE/INSERT мы транзакцию всегда можем "пощупать" т.к. работа механизма N2 вполне себе видна

По SELECT

Приведу практический пример. Вы написали микро-сервис который возвращает инфу по клиенту.
Двумя методами. getBrief(clientId), getFull(clientId). Грубо говоря смотрим в виджет который показывает
краткую сводку. А потом кликаем мышкой и видим детализацию. Паттерн норм? Вполне себе норм.
Продкутовый кейс. Такое часто бывает.

Это две операции select. Но между этими операциями база могла изменятся. И клиент мог
менять какие-то свойства. Ну... по крайней мере бизнес говорит что такое вполне себе возможно.
Чего-ж нет то?

Вот и вопрос следующий. Эти два селекта мы рассматриваем в изоляции от изменений БД? Тогда мы должны
соотв зафиксировать режим транзакций и получить согласованный снимок.

Или мы просто делаем 2 независимых селекта и получаем теоретически разные сеты атрибутов клиента.

Leonid KudryavtsevmaytonВы написали микро-сервис который возвращает инфу по клиенту.
Двумя методами. getBrief(clientId), getFull(clientId). Грубо говоря смотрим в виджет который показывает
краткую сводку. А потом кликаем мышкой и видим детализацию. Паттерн норм? Вполне себе норм.
....
и получить согласованный снимок.

Нифига не норм. Как минимум метода "refresh" не хватает )))

получаем статическую фигню, которая всегда возврашает старые данные на момент первого логина юзера

данные может и согласованные, но ... "такая фигня получается" ( C )
Я вас умоляю. Никто дополнительную кнопку с Refresh не будет делать. Это и по дизайну и по нагрузке
- ненужная фигня.

Просто я подчеркиваю что SELECT может быть "не так прост...."

PetroNotC SharpLeonid Kudryavtsev,
Этот юзкейс есть в любой системе в принципе.
orm.ПроверитьНаДолги(Имя
orm.ВыдатьКредит(Имя
Между первым и вторым всегда может ситуация измениться.
Это риски и не надо тут блокировать.
Боже упаси. Я и не предлагаю блокировать.

Нормальный SELECT (как в Оракле) вообще никогда и ничего не блокирует.

Я вообще не понимаю Фаулера здесь. Может его перенести в Программирование или в Проектирование БД

В форуме Java имеет смысол посмотреть с ракурса JDBC/JPA и через призму этих пром-стандартов.