Это старая версия
Chilim/dRS за 2008-11-17 19:45:22..
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. Репликация: может производиться как в одну сторону (все объекты, измененные со времени последней репликации, отсылаются от одного провайдера второму) так и в обе (тогда повторяется та же операция, но от другого провайдера). Для определения поведения программы при конфликте необходимо создать Listener и перегрузить его метод
public void onReplicate(Replication Event? event).
У программы-репликатора должен быть доступ непосредственно к базам данных (в отличие от RDBR, где взаимодействуют приложения); все прочие приложения/обертки игнорируются.
5. Репликация удаленных объектов: проводится отдельно от остальных объектов. По умолчанию при конфликте объект удаляется. Каскадное удаление не поддерживается.
6. Подтверждение репликации: все изменения сохраняются в базы данных (для обеих сторон)(?).
Вся сессия рассматривается как одна транзакция. Вызов метода rollback() приводит к отмене всех изменений с начала сессии.
