Написание распределенной базы

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

На вскидку есть две проблемы:
1. Конфликты репликации
2. Приход почты пользователю до того момента, как изменения отреплицируются на нужный сервер

0

чтото рядом обсуждали

0

Да, но в той теме разбирались как реплицировать документы на различные сервера... Здесь вопросы - как избежать проблем, связанных с репликацией - конфликты репликации, например.

Предлагаю вопрос поставить так: как вы боретесь с конфликтами репликации (с причинами их возникновения)?

0

в той теме предлогалось обмениваться идеями относительно настройки схемы репликации

про конфликты, есть список рекомендаций, одни из основных пунктов:
- не создавать ситуаций в которых редактировать документ может несколько человек, либо уменьшить это кол-во до минимума, этого можно достичь с помощью правильного доступа к документу и базе (authors/readers-fields, ACL);
- устанавливать на форме свойство управления конфликтами в "сливать" (Conflict handling = merge), тогда, если были изменены разные данные в документе, то и конфликт создан не будет, и изменения не будут потеряны, этого можно достичь устанавливая доступ к различным частям документа (Controlled Access Sections);


а вообще, то поняв причины возникновения конфликтов, будет намного проще найти способы борьбы с ними!
но многие программисты пытаются найти решение не понимая почему возникают конфликты...

рекомендую почитать Inside Notes, ch. 9. Replication

0

Сообщение от fedotxxl Предлагаю вопрос поставить так: как вы боретесь с конфликтами репликации (с причинами их возникновения)?

Поищите по Replication or save conflicts в административном хелпе, там есть общие рекомендации.
А также посмторите про Lock документов.

0

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

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

0

alb
Угу, об этом и говорю.

У меня идея такая - позволять редактировать документ только на одном сервере. Если нужно на другом - переключать, но там потребуется время на переключение (пока репликация со старого сервера на новый не пройдет). Реализовать сложно, но исключит конфликты репликации. Но нужно ли так гимороиться?

0

Сообщение от alb создовать копии основного документа для каждого начальника тоже некрасиво

вот зря ты так думаешь
если красиво реализовать, то все красиво :(
например, есть такой продукт IBM Lotus Workflow, в нем для одновременного выполнения задачи используется именно такой принцип - для каждого исполнителя свой документ, основная проблема при этом - как правильно документ размножить, а потом слить?!..

0

Akupaka
Ну да, больше там проблем нет) Только эта, зато какая =)

Моё предложение. Внимательно читаем и ищем дыры:
Есть БД "Блокиратор", которая лежит на одном сервере (X). Есть БД "Приложение", которая лежит на куче серверов (Y1, Y2...). Все сервера Y могу коннектиться к серверу X

Каждый документ привязан к какому-то серверу. Каждый документ может быть залочен на привязанном сервере каким-либо пользователем. Всё это знает БД "Блокиратор".

Итак, нам нужно отредактировать документ на сервере Y1. Мы посылаем запрос в БД "Блокиратор".

Обработка запроса на блокировку документа на сервере Y1 (всё делает БД "Блокиратор")
1. Проверяем, к какому серверу в данный момент привязан документ (doc1 в БД "Блокиратор"). Если не к серверу Y1 - отказ с описанием ошибки
2. Проверяем, не заблокирован документ на сервере Y1 (doc1 в БД "Блокиратор"). Если заблокирован - отказ с описанием ошибки
3. Последняя проверка. Смысл её в том, чтобы узнать, прошла ли репликации с момента перевода заявки с сервера Y2 на Y1.
Открываем документ на сервере Y1 и смотрим содержимое поля Main_Server. Если Main_Server != "Y1", то репликация ещё не прошла - выдаем ошибку

Если ошибку не выдали, то блокируем документ и возвращаем true

Мы попытались отредактировать документ на сервере Y2 и получили ошибку, что документ привязан к серверу Y1. Нам было предложено открыть документ на сервере Y1, но нам проще изменить сервер документа (т.е. переключить документ на сервер Y2). Посылаем запрос в БД "Блокиратор"

Обработка запроса на изменение сервера документа с Y1 на Y2 (всё делает БД "Блокиратор")
1. Пытаемся заблокировать документ на сервере Y1. Если получаем ошибку, то выдаем её и выходим
2. Изменяем поле "Main_Server" в документе на сервере Y1: FIELD Main_Server := "Y2"
3. Изменяем в БД "Блокиратор" на сервер Y2 (документ doc1)

Повторяю, смотрим, ищим дыры, комментируем...

0

Зачем это, если есть стандартный document locking?

0

Medevic
Он же работает только в пределах одного сервера... Если бы стандартный document locking спасал от конфликтов, то и проблемы бо не было... Хотя вопрос нужно ли так всё гимороить всё же стоит

0

Сообщение от fedotxxl Он же работает только в пределах одного сервера... Если бы стандартный document locking спасал от конфликтов, то и проблемы бо не было... Хотя вопрос нужно ли так всё гимороить всё же стоит

А твоя БД Блокиратор лежит не на одном сервере?
Он спасает.
Хотя чего их так бояться? Ну бывают иногда конфликты. Если правильно делать, то их количество сводится к минимуму.

0

fedotxxl

Тогда уже лучше смотреть в сторону CAPI так как фактически визы можно сделать отдельными доками, а метку о визах ставить программно, что какбы детерминированно может привести к конфликтам, которые можно разрулить с помощью

Capturing the Domino or Notes Replication Conflict Notification

By trapping the replication conflict notification, you can have an extension manager automatically handle replication conflicts. The extension ID code is EM_NSFCONFLICTHANDLER. There is no corresponding API function for thys operation. The header file extmgr.h documents the arguments to the replication conflict handler.

The Notes C API Release 4.5 introduced several new functions that can be used by the extension manager to determine how to handle a replication conflict. These functions include:

NSFNoteFindMatchingItem Find item in one note that matches the same item in another.
NSFNoteFindDivergenceTime Find when two notes were last in synch.
NSFItemGetModifiedTime Get the last modified time for an item.
NSFItemGetModifiedTimeByBLOCKID Get the last modified time for an item, given the items BLOCKID.

Use the extension manager callback routine to handle the replication conflict. In thys handler routine, you can use NSFNoteFindMatchingItems to pair items from one note that match items from another. An item pair may be in conflict if one of the items modified time is later than the notes divergence time. You can then specify the desired value for the item by setting thys item value in the item of one note and deleting thys item from the other. Then, pass CONFLICT_ACTION_MERGE back so that the two matching notes are merged with your specified resolution to the conflict.

If you want Domino or Notes to handle the replication conflict, pass back ERR_EM_CONTINUE. For example, if an error occurs in your replication conflict handler you may want to abort handling the conflict yourself and pass ERR_EM_CONTINUE back to Domino or Notes.

The replication conflict handler needs to be installed on each Domino or Notes installation that can be involved in the replication and subsequent conflict resolution. Domino or Notes calls the extension manager replication conflict handler (if any) on the installation that lost the replication conflict.

The sample program misc\extconf demonstrates an extension manager that handles a replication conflict.

0

Сообщение от Medevic Хотя чего их так бояться? Ну бывают иногда конфликты. Если правильно делать, то их количество сводится к минимуму.

плюсадын

0