MyWackoSite: 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 и перегрузить его метод

У программы-репликатора должен быть доступ непосредственно к базам данных (в отличие от RDBR, где взаимодействуют приложения); все прочие приложения/обертки игнорируются.

5. Репликация удаленных объектов: проводится отдельно от остальных объектов. По умолчанию при конфликте объект удаляется. Каскадное удаление не поддерживается.

6. Подтверждение репликации: все изменения сохраняются в базы данных (для обеих сторон)(?).

Вся сессия рассматривается как одна транзакция. Вызов метода ReplicationSession.rollback() приводит к отмене всех изменений с начала сессии.