Lotsia PLM: Форум по семейству систем PLM/PDM/TDM/ERP/Workflow

мы опять стали налетать на двойные номера.... (2 одинаковых из 2000 сформированных) разница в захвате - доли секунды
правда для нас не очень принципиально - поскольку мы разруливаем через 'хвостики' юзеров - типа номер+тире+id юзера
(для нулевого филиала - все ок - для остальных страшновато конечно - оч много нулей в id юзера, - но это тоже решаемо)
сейчас/сегодня перешли на совет СК - действие из действия (посмотрим что будет)
1. передать в действие - объект содержащий номер
2. передать в действие - атрибут содержащий номер
3. в действии - чтение атрибута
4. в действии - запись атрибута с инкременом
5. в действии - Update
6. вернуть из действия номер

а у вас как дела с этим - по какому пути пошли?
как Disillusioned или как Юрий или как СК?

а запуск еще одного действия - это принципиально лучше?
те же шаги можно провернуть и в одном действии, обставив нужный блок Update'ом..
или нет?

У нас просто реализованно. Уникальные номера по порядку у нас только в одном модуле используются.
Мы завели таблицу счетчик и при первом обращении выставляем блокировку на уровне БД.
Это гарантирует что значение из таблицы может считать только один пользователь. Затем идет
наращивание счетчика и разблокировка по завершении транзакции. Все проблемы нет.

ух ты.. блокировка на уровне БД - это каким образом?

Anderyt писал(а):ух ты.. блокировка на уровне БД - это каким образом?

Прочитай про команду SET TRANSACTION ISOLATION LEVEL для MsSQL

>Anderyt

а запуск еще одного действия - это принципиально лучше?

ну типа СК говорил что это отдельная транзакция... вроде вероятность меньше, наверно
а в БД честно говоря неохота программировать

ps
хотя штук 30 своих процедур и функций активно используются- в основном для поиска и отчетов и списков - но не для чего более

А без БД никак не получиться, для этого и был придуман механизм блокировок.
Или можно идти по пути лоции (генерация ид). Т.е. для каждого пользователя свой диапазон номеров.
Т.е. счетчиков столько, сколько пользователей.
Или перейти на GUID, если это подходит по смыслу. Тут вообще ничего контролировать ненадо.

хоть мы и без техподдержки - но я все равно питаю иллюзию что далеко 'от Лоции отходить' не стоит...
ведь только перейдешь черту - и понеслась душа в рай...

Дело в том, что в Лоции не реализован механизм блокировки необходимых данных.
А база работает в многопоточном режиме и поэтому нет гарантии, что данные считанные
разными клиентами не совпадут.
Даже в программировании многопоточных задач реализован механизм блокировки для
сохранности целостности данных. Но автоматически это не работает.
Поэтому программист сам должен решать к каким данным установить последовательный доступ.
При не правильной реализации блокировок можно полностью потерять мультизадачность.

И кто говорит что надо именно в базу лоции добавлять счетчик. Это может быть
абсолютно любая база хоть MySQL.
А доступ к ней осуществлять через скрипт.