Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Ну это как-то совсем off-topic 04.08.05 21:46 Число просмотров: 1922
Автор: leo <Леонид Юрьев> Статус: Elderman
|
Во всех Version-Control (cvs, subversion, sourcesafe, perforce, etc...) блокировка делается только при изменении файла и только сервером при обработке запросов.
С базами данных это несравнимо сложнее. Для возможности одновременной обработки запросов от нескольких процессов (пользователей) и параллельной обработки, придумали массу видов блокировок. Отдельные записи (строки), иногда столбцы, таблицы и т.д. Поэтому сравнение с source-contorl совершенно неприменимо...
Хотя, в бытность продвижения Oracle 8i, я до хрипоты спорил с одним из "продвигалетей". Убеждая его, что для "малого бизнеса" решение с единым глобальным lock-ом (single-write/multi-read) на уровне БД (как совокупности таблиц) и хостом с одним-двумя CPU, в целом будет лучше.
По сути это я и предложил сделать в обсуждаемом случае. Проблема в том, что нельзя сделать достаточно эффективно, без разбирательства с семантикой ООП-доступа к БД из внутренностей 1С. Чего делать очень не хочется, там более 100 функций-методов.
Основная текущая реальная проблема в очень многих системах типа 1С в том, что в разные моменты времени нужно блокировать разное подмножество объектов (таблиц). И благодаря ООП, стремлению к универсальности и ленивости/тупости прикладных программистов, это множество объектов становится определимо только во время выполнения кода. Поэтому "классическая" тактика разделения доступа непременима (dead-lock), а из всего другого самый легкий выбор - итеративный "тупизм".
|
|
|
подробно о проекте
Анализ криптографических сетевых...
