Petro123Тогда почему, спринг управляет транзакциями декларативно.

Управляет транзакциями разработчик. Декларативное управление лишь один из инструментов. Вопрос в стиле "почему вода мокрая"?

Petro123Почему программист должен руками управлять связкой: СессияХибера ---СессияHTTP.

Почему программист вообще что-то должен делать? Наверное потому что ORM и Web это совершенно разные технологии. И каждый склеивает их как хочет. Не нравится Spring-клей? Берем Seam-клей или EJB-клей. Не нравится ничего готового? Пишем руками. Это везде так.

Petro123Если время жизни объектов явно выше одного запроса HTTP.

8) Время жизни объектов не важно. Время жизни сущностей в любом случае больше HTTP запроса.

Petro1233. Тут кто-то говорил, что сессиями программисту лень заниматься. Они у него ВНИЗУ автоматом.
Кто говорил? Где говорил? Именно такими словами?

Йуный джавистЪОбязательно. Если данных мало и запросы хорошо ложатся в дисковый кэш СУБД, то СУБД без проблем выдерживает несколько десятков тысяч запросов в секунду на ноутбуке девелопера, и извращения с кэшем не нужны.
Угу, а выполнение SQL запросов и передача данных между Java сервером и СУБД - бесплатная операция.

Йуный джавистЪЕсли данных много, то скажется, во-первых, жуткий оверхед по памяти
Кеширование это всегда "жуткий оверхед по памяти". Кеш с нулевым размером ещё пока не изобрели. Впрочем, как и вечный двигатель.

Йуный джавистЪкоторый в яве присутствует на каждый объект (сравните с ораклом, где даже целые числа имеют переменную длину для экономии каждого байта)
Планка памяти стоит меньше чем день работы Java программиста. А в облаке, возможно, ещё дешевле.

Йуный джавистЪа во-вторых, сборщик мусора будет все время перебирать этот кэш, что приведет к неслабым тормозам.
Проблеме уже много лет и она успешно решается. Off heap кеш, G1 сборщик.

rdmКак я понял автора темы, ему требуется что-то типа пессимистической блокировки на продолжительное время.
Так что как по мне, лучше загрузить detached объект в HTTP сессию, редактировать его там, а при сохранение проверять версию.
Нет. Автор темы лишь спрашивает об этом подходе, как о варианте решения своих проблем. Это не значит что оно ему нужно с точки зрения бизнес-требований. Скорее всего вообще не нужно, потому что уже что-то написано и работает без этого.

Йуный джавистЪА что, есть какой-то работающий off heap кэш для явы?
Помимо BigMemory? Любое внятное NoSQL хранилище.

Йуный джавистЪПомимо BigMemory? Любое внятное NoSQL хранилище.
Вы предлагаете, имея оракл, поставить впереди него какое-то NoSQL хранилище? Это мне напоминает анекдот про крестьян, которым показали трактор, объяснили, а они отвечают:
- Мы поняли, это все хорошо, внутреннее сгорание, бензин, но лошадь-то куда запрягать?
Аналогия не уместна. Можете сколько угодно писать в каждой теме Java - говно, Oracle RDBMS - рулит. Сомневаюсь что автору темы это интересно.

Petro123по поводу кеша первого уровня.
Если разговор всё ещё о Hibernate, то "кеш первого уровня." это Session. Время жизни которого, в большинстве случаев, одна транзакция.

Petro123Можно сколько угодно спорить о его нужности.

Это не нужность. Это неизбежность. Или ты таки о втором уровне ?

Petro123Но пока программист не напишет волшебную фразу - сбросить в БД. А параллельный юзверь - перечатать из БД, изменения друг друга они не увидят.
Ведь так? Т.к. хранилище всё таки в БД, а не в хибере.
Разговор тракториста и мотоциклиста, блин. Юзеры не ходят в базу мимо кеша 2го уровня. Поэтому он всегда актуален.
Программист не пишет волшебных фраз параллельно с доступом юзера к БД.