Alexey KuznetsovТеперь понял.

Тогда остается еще такое решение: делаете маркерное поле и выборки делаете с учетом маркерного поля, что бы другие коннекты не тащили "логически незакомиченные" данные.

Что бы упростить написание запросов, таблицы можно вьюхами обернуть, которые автоматом отфильтруют данные.
Я один раз похожее решение использовал: флажок "IsDeleted" который приходилось постоянно иметь ввиду при написании запросов, муторно, но другого выхода думаю нету.Ваше решение не подходит по нескольким причинам:
1) Как быть с новыми записями? Т.е. которые созданы пользователем, но еще не закомичены?
2) Флаг isDeleted будет действовать и на всех остальных пользователей. Т.е. один юзер что-то удалил, но еще не сохранил, при этом все остальные юзеры уже увидят эти изменения. Это неправильно.

Alexey Kuznetsovsvenom1) Как быть с новыми записями? Т.е. которые созданы пользователем, но еще не закомичены?
2) Флаг isDeleted будет действовать и на всех остальных пользователей. Т.е. один юзер что-то удалил, но еще не сохранил, при этом все остальные юзеры уже увидят эти изменения. Это неправильно.

флаг IsDeleted я привел для своего случая, у вас видимо будет что-то более сложное, скорее всего поле с ID "логической" транзакции.Ну это все равно велосипед, так как у автора есть апп. сервер и именно он должен хранить состояние сесии пользователя, а не СУБД. Ваш подход подошел бы в двухзвенке или каких-то особых случаях трехзвенки (например - кластер с сохранением состояния в БД).
Какие минусы:
1) Лишние операции с СУБД, лишний сетевой траффик
2) Проблемы с поддержанием целостности информации. Например, пользователь удаляет какую-то строку, потом пытается сохранить изменения, но в этот момент апп. сервер падает (вырубили электричество, а ИБП замкнуло ). В итоге, после рестарта сервака в СУБД имеется запись об удалении, которая уже не связана ни с какой сессией и вообще ХЗ что с ней делать.

slippery,
Ну тогда реализуйте эту логику на уровне БД, как Alexey Kuznetsov предлагал выше. Придумываете некую таблицу (или таблицы - одну для изменений, другую - для удалений, третью - для созданных записей), в которой будут храниться изменения, например
CREATE TABLE ... (
id,
session_id,
table_name,
...
)
Тут ключевое поле - session_id - идентификатор сессии. Дальше фикачите кучу всяких вьюшек, которые будут отображать данные с учетом изменений пользователя. Далее навешиваете на эти вьюхи триггеры, которые будут не только сохранять изменения в релаьные таблицы, но и будут чистить вспомогательные. Далее создаете какую-либо джобу, которая будет периодически подчищать "мусор" во вспомогательных таблицах после нештатных ситуаций (напр., вырубили электричество, как я говорил выше).
Далее навешиваете на сессию пользователя листенер, что бы при закрытии сессии, чистились записи, относящиеся к этой сессии, во вспомогательных таблицах.

Минусы - лишний траффик в БД до коммита пользователя, много дополнительного кода на уровне СУБД. Плюсы - автоматом решаются проблемы с пейджингом.

Йуный джавистЪМне тут пришла мысль, как можно решить задачу с использованием только коротких транзакций.
Решение не использует Hibernate.
1)Все изменения таблицы храним в Http сессии. Изменения - это три списка:
-- список id удаленных строк
-- список новых строк
-- список измененных строк
2)Пока пользователь редактирует данные(создает, изменяет или удаляет строки), http запросы обрабатываются по такой схеме:
-- открываем транзакцию
-- скидываем изменения в БД(создаем, удаляем и изменяем строки, в соответствии со списками пункта 1)
-- дальше делаем запросы для получения нужных данных (пейджинг и прочее). Так как изменения скинуты в БД, пейджинг и все остальное будет работать правильно.
--в конце обработки http запроса откатываем транзакцию
3)Если пользователь решает отменить все изменения, то удаляем списки из пункта 1.
4)Если пользователь решает применить изменения, то скидываем изменения в базу и комитим транзакцию.В вашем решении абсолютно не важно будет использован Хибер или нет. Если да - просто делаем flush(), а потом откатываем.

slipperyЙуный джавистЪМне тут пришла мысль, как можно решить задачу с использованием только коротких транзакций.
Решение не использует Hibernate.
1)Все изменения таблицы храним в Http сессии. Изменения - это три списка:
-- список id удаленных строк
-- список новых строк
-- список измененных строк
2)Пока пользователь редактирует данные(создает, изменяет или удаляет строки), http запросы обрабатываются по такой схеме:
-- открываем транзакцию
-- скидываем изменения в БД(создаем, удаляем и изменяем строки, в соответствии со списками пункта 1)
-- дальше делаем запросы для получения нужных данных (пейджинг и прочее). Так как изменения скинуты в БД, пейджинг и все остальное будет работать правильно.
--в конце обработки http запроса откатываем транзакцию
3)Если пользователь решает отменить все изменения, то удаляем списки из пункта 1.
4)Если пользователь решает применить изменения, то скидываем изменения в базу и комитим транзакцию.

хм.....интересный вариант, мне только от хибера отказываться нельзя, таково требование не рушимое, но сама идея интересна,
к примеру на хибере
1) есть "главная сессия" она открывается при первом запросе
2) все удаления, добавления проводятся через "главную сессию"
3) при выборках "главная" сессия клонируется(если такое возможно, я не знаю) , открывается транзакция в клонированной сесии, сбрасывается(флаш) выполняется выборка, транзакция откатывается и клонированная сессия закрывается
4) в итоге при завершаещем коммите либо сбрасываем(флэш) "главную" сессию либо закрываем ее

Кто что думает? возможен ли такой вариант? если возможен в чем его минусы?Не прокетит. Еще раз повторяю - сессия Хибера не прденазначена для решения этой задачи, ее нельзя сюда пихать в принципе. Йуный джавистЪ предлагает немного модифицированное мое решение: создаем все ту же структуру в Http сессии. На каждой операции чтения происходит следующее - все изменения сначала сбрасываются в базу (не важно как - хотите через JDBC, хотите через Хибер - пофиг), после этого происходит считывание необходимой информации, а потом откат транзакции.

slipperysvenom, а можете объяснить почему не прокатит???
ведь сессия хибера и так в себе содержит подобные структуры что вы предлагаете сделать руками(то есть хранит что надо удалить что обновить и т.д.)
почему если клонировать сессию то не получится? хотя возможно ее нельзя клонировать, этого я не знаю1. Сессия Хибера не содержит реализации метода clone().
2) Ее нельзя сериализовать-десериализовать, так как в ней присутствуют несериализуемые зависимые объекты (транзакция, коннекшн и т.д..)
А когда вы делаете flush() вы изменяете состояние сессии и нельзя потом заставить сделать ее этот же flush() еще раз.