Тут два момент.
Настроить логгер на запись в базу, не проблема. Так же не проблема настроить логгер писать только те логи в которых SQL запросы хибера. Это все решается с log4j без особых трудностей.

Трудности вызывает вторая часть вопроса. Подразумевается что эти запросы потом надо будет переиспользовать? А они все имеют вид для PreparedStatement то есть "... WHERE column = ?"
И вытягивать реально подставляемые значения задача не тривиальная.

Но в этом случае, я бы написал обертку над JDBC драйвером, которая сможет логировать заапросы наряду со значениями.

Кстати, вопрос, из ряда
"У меня есть не скажу какая задача, и я её решаю таким способом. Как мне этот способ осуществить?"
Если расскажешь более общую задачу, может подскажем решение получше.

samumИзвиняюсь, критику принял :[
В более общем виде стоит задача оранизовать (т.е. сначала предусмотреть такую возможность) что-то вроде репликации.
Да, здесь и на других форумах процентов 80 таких вопросов. Никак не могу придумать определение этому феномену.

samumСуществует N равноправных офисов, в каждом менеджеры вводят и просматривают данные (объем вставки/изменения данных сравнительно мал, изменятьданные могут только в офисе, в котором они изначально вводились). По возможности во всех офисах должна быть максимально одинаковая (и свежая) инфомация. Посадить их всех на единую БД нет возможности в основном из-за качества связи. В данном случае лучше наличие несколько устаревших данных, чем прекращение работы целого офиса в случае очердного обрыва связи.
Отсуда и решение - лог вносимых изменений в бд с периодической (или моментальной) его отправкой. Синхронизация...
Я бы начал решать задачу с поиска средств репликации прежде чем писать свою репликацию. И начинать поиск стоит как раз с базы данных. Это конечно уже отдельная тема для другого форума, но комерческие SQL сервера имеют вполне себе нормальную репликацию как раз для твоего случая. Для некомерческих есть ряд решений, которые можно к ним прикрутить.

Так же я уверен, что существуют средства репликации реализованые на Java. Самому сталкиватся не приходилось. Но сомневаюсь что гугл не может в этом помочь.

А вот если ты рассмотришь эти варианты и поймешь что тебе они не подходят. То тогда выкладывай эту самую причину сюда. И тогда можно обсуждать и свою репликацию в рамках этой причины.

TiGДаже логирующие триггеры на всех изменяемых таблицах и то более правильным решением будут.
Но лучше все-таки поискать штатные механизмы, и проще и правильнее и меньше проблем потом будет.
С учетом того что проблемы даже с каналом, не исключено что и БД - Access. 8))

Kachalov- как вариант: JMS
Это же все данные конвертировать в подходящую форму, а потом ещё и рассылать по узкому каналу? Или как?

Kachalov- создаем DataObject, пихаем его в Message, Message отправляем в очередь, когда связь с центральным офисом (ЦО) восстановлена мессаджи от сабоффиса (СО) отправляются в ЦО, а мессаджи из ЦО в СО, происходит синхронизация данных между СО и ЦО. Прикидка грубая, это всего лишь вариант :)
Лично мне на первый взгляд подобное решение кажется слишком сложным. Не понятно как гарантировать синхронность с состоянием базы.

TiG Blazkowicz Лично мне на первый взгляд подобное решение кажется слишком сложным. Не понятно как гарантировать синхронность с состоянием базы.Как раз наоборот, схема с единым центральным узлом будет проще в сопровождении и самое главное надежнее и более производительна (последнее - исходя из посыла о качестве связи). Опять же разрешение коллизий проще делать на центральном узле. И особенно, если будет решено делать репликацию самостоятельно ;)
Кроме того, централизованный сервер репликации можно использовать и еще для одной очень полезной вещи - гонять на нем отчетность к примеру. В среднем (по всем филиалам) он будет находиться в наиболее актуальном состоянии. что уж говорить про скорость получения нужной информации по сравнению с опросом всех филиалов.
На словах и в теории оно все красиво. Но я себе слабо представляю как должна работать репликация на уровне объектов так чтобы в чем-то превзойти репликацию на уровне БД.

Kachalov TiGА то что не следует изобретать своих велосипедов, если можно найти готовый - см. мои посты выше.
- как называется "готовый велосипед" и где его можно скачать?
Репликация в том или ином виде существует для всех основных вендоров БД. Даже Master2Master. Хотя наверное, кроме SQL Server и Orcale с Master2Master вряд ли кто-то адекватно справляется.