Chilim/dRS
dRS
dRS – это проект который был создан для репликации специфических объектных баз данных 
db4o, и баз данных, с которыми может работать Hibernate (Официальный сайт(англ), Википедия).
для того, чтобы приложение, использующее dRS могло отреплицировать какую-либо базу данных, ему нужно указать путь к двум конфигурационым файлам Hibernate, в которых хранятся настройки самого Hibernate, и в том числе адрес базы данных(которая должна уже существовать), имя пользователя и пароль.
//TODO
Once More
dRS – система репликации баз данных, изначально написанная для db4o (db4o= database for objects, объектная база данных), но также способная реплицировать другие БД при помощи Hibernate. Hibernate – это библиотека, реализующая ORM(Object-relational mapping) – отображение системы объектов в базу данных. Это значит, что мы можем сохранять объекты в виде строк таблиц, каждому классу объектов соответствует таблица БД.
Далее рассматриваем только репликацию Hibernate to Hibernate.
Реплицирующиеся БД называются провайдерами. Список провайдеров, с которыми реплицировалась БД хранится в таблице drs_providers (которая добавляется репликатором в БД. Еще две создаваемые в БД таблицы drs: drs_history и drs_objects) Для репликации у инициатора должны существовать конфигурационные файлы Hibernate (hibernate.cfg.xml) для обеих сторон. В таком файле прописаны настройки Hibernate, путь к базе данных, имя пользователя и пароль.
Репликация происходит так.
1. Инициализация: проверка того, что указанные в конфигурации провайдеры существуют, что пользователь с данным паролем существует и у него есть необходимые права. Иначе – вылетает исключение.
2. Версии. Каждой успешно завершенной репликации соответствует запись в специальной таблице – drs_history. В записи содержится информация о провайдере и об установленной версии БД (после репликации двум базам данных присваивается одинаковый номер версии – максимальная из версий всех объектов из двух БД + 1). В начале репликации проверяются номера версий, установленных после последней репликации друг с другом. Если они не совпадают, репликации не происходит.
3. Поиск измененных объектов. Список измененных объектов строится по номерам версий объектов (если номер версии объекта больше всех номеров версий в записях о репликации, то он был изменен после последней репликации). (Отсюда следует, что создание и изменение объектов как-то отслеживаются; возможно, тем же методом, что и у нас.) Информация об объектах хранится в таблице drs_objects.
4. Репликация: может производиться как в одну сторону (все объекты, измененные со времени последней репликации, отсылаются от одного провайдера второму) так и в обе (тогда повторяется та же операция, но от другого провайдера). Для определения поведения программы при конфликте необходимо создать ReplicationEventListener и перегрузить его метод
public void onReplicate(ReplicationEvent event).
У программы-репликатора должен быть доступ непосредственно к базам данных (в отличие от RDBR, где взаимодействуют приложения); все прочие приложения/обертки игнорируются.
5. Репликация удаленных объектов: проводится отдельно от остальных объектов. По умолчанию при конфликте объект удаляется. Каскадное удаление не поддерживается.
6. Подтверждение репликации: все изменения сохраняются в базы данных (для обеих сторон)(?).
Вся сессия рассматривается как одна транзакция. Вызов метода ReplicationSession.rollback() приводит к отмене всех изменений с начала сессии.