Организация счетчика

[iivvnn]

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

 

[lmike]

-ввести пулы номеров, кот. сервера будут пераспределять. Т.е. генерим мульён номеров, кот. попеременно закрепляем за серверами и реплицируем пул на сервера, когда пул подходит к опред. отсечке - генерим ышо и реплицируем
-использовать UNID
-ввести в состав номера номер сервера
-ввести практику временных номеров, а глобальные будут формироваться по опред событию (на основе временных)

 

[iivvnn]

Как использовать UNID в организации порядковой нумерации (№+1)?

Тетка хочет при нажатии "Создать док" и открытии формы сразу видеть номер документа (до его сохранения). В таком варианте реплицировать пулы (еще при хреновом канале связи?)

 

[lmike]

в организации порядковой нумерации (№+1)?

вам не кажется, что это отсутствовало в начальной постановке вопроса?
а простите - зачем +1?
и где вы видели схему с репликацией и нумерацией +1? (пример в студию) если нумерация не происходит только на одном узле

 

[1KIA]

я делала так: на одном сервере (админ.) сделала форму, в которой поле с заполненем номера. На postopen берется номер указанный там, на кверисайв изменяется номер на 1, т.е. в той форме, в которой поле с заполненем номера.

 

[lmike]

я делала так: на одном сервере (админ.) сделала форму, в которой поле с заполненем номера. На postopen берется номер указанный там, на кверисайв изменяется номер на 1, т.е. в той форме, в которой поле с заполненем номера.

речь о двух серверах, и всё что вы делали - это UI приблуды и работать при многоюзеровом доступе не будет

 

[iivvnn]

Ситауция: в Одессе(к примеру) сидит юзер который создает доки от Одессы (нумерация - последний № док из вьюхи+1). Все четко работало - репликой подтягивалась в основную базу инф в Киев. Пока в Киеве не посадили чела которому дали права вводить доки от имени Одессы.
И вот эти двое начинают активно вводить документы - тот у себя тот у себя - репликация 1 в час. Дубликаты номеров рулят!!!

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

 

[Caspiy]

Канал постоянный? или Dial-Up (подключаемый по расписанию)?

Если постоянный, то как вариант:
1. создаете БД (с документом счетчика)
2. сервера объединяете в кластер (если есть такая возможность)
3. для кластерной репликации помечаете только БД с документом счетчика
4. меняете код (нумератора) для работы с этим документом счетчика.

Кластерная репликация работает в реальном времени. За счет того, что меняется только 1 документ, данные будут передаваться практически мгновенно! (сам постоянно использую данный способ в распределенных системах единой компании).

 

[iivvnn]

Канал постоянный.
Насколько я помню в класте могут обьединяться сервера только одной поименнованой сети? Или ошибаюсь - (сервера в разных NNN)

PS - а где для серверов кластера выставить реплицировать только одну базу?

 

[lmike]

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

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

Добавлено:

а где для серверов кластера выставить реплицировать только одну базу?

в базе кластера (хэлп админа)

Добавлено: через админский тулз

Ссылка скрыта от гостей

Добавлено: а еще надо учесть

You should schedule replication in a cluster on a regular basis to be sure that databases are properly updated even when they aren't replicated by the Cluster Replicator.

т.е. кластерная репликация - это не абсолютная гарантия

 

[Cleric-Lviv]

iivvnn

Я например делаю нумерацию на основе UNID (так как и предлагал lmike ) очень удобно так как если привязать номер к UNID то можна бить увереним что нумерок не повторится.

 

[Gandliar]

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

 

[Caspiy]

Добавлено: а еще надо учесть

You should schedule replication in a cluster on a regular basis to be sure that databases are properly updated even when they aren't replicated by the Cluster Replicator.

т.е. кластерная репликация - это не абсолютная гарантия wink.gif

Для подстраховки конечно надо дополнительную репликацию проводить, но пока с кластерной проблем не наблюдалось (с 2006 года, все работает на отлично)

Добавлено:

Я например делаю нумерацию на основе UNID (так как и предлагал lmike ) очень удобно так как если привязать номер к UNID то можна бить увереним что нумерок не повторится.

так то оно конечно уникально получится! Но многим требуется определенный вид номера (а не просто набор из 32 символов)

PS: если содержание номера "по барабану", то можно и формульную функцию "@Unique" использовать!