авторПри работе с базой данных тип используемого инструмента для блокировок не имеет никакого значения. Все разница в быстродействии исчезнет на фоне работы с данными

Ну смотрите, допустим нужно прочитать 3 миллиона записей из таблицы чтобы составить некий сводный отчет. Если мы используем CriticalSection - все остальные клиенты не смогут ни читать, ни писать пока идет чтение данных. А в случае MREW - остальные смогут читать и только некоторые не смогут писать. Поскольку запись у нас реже чтения - это критично.

авторТак может просто потоки неправильно настроены? Для SQLite каждый поток должен иметь свое собственное соединение с базой и с включенной опцией мультитрединг.

Тут все правильно. Сама дллка собрана с опцией мультитрединг и какждый поток создает свое подключение к базе. Но ограничение на один пишущий поток и на модификацию sqlite_master - это описано в доках sqlite и это (конкретно в нашем случае) нужно разруливать.

авторДля этого используются временные таблицы.

Насколько я понял из доков Sqlite - временные таблицы удаляются когда закрывается последнее соединение к базе. Т.е. при перезапуске сервера временные таблицы потеряются.

Вот на stackoverflow https://stackoverflow.com/questions/1680249/how-to-use-sqlite-in-a-multi-threaded-application пишут:

Your sqlite3_step, sqlite3_prepare and some other calls may return SQLITE_BUSY or SQLITE_LOCKED. SQLITE_BUSY usually means that sqlite needs to acquire the lock. The biggest difference between the two return values:

SQLITE_LOCKED: if you get this from a sqlite3_step statement, you MUST call sqlite3_reset on the statement handle. You should only get this on the first call to sqlite3_step, so once reset is called you can actually "retry" your sqlite3_step call. On other operations, it's the same as SQLITE_BUSY
SQLITE_BUSY : There is no need to call sqlite3_reset, just retry your operation after waiting a bit for the lock to be released.

Вот ради того чтобы этого избежать все и делается.

В остальном, я думаю, вопрос можно закрывать. Попробуем это:

авторТот который эксклюзивно пишет, вначале делает AtomicIncrement(FWrite) и event.reset в конце AtomicDecrement(FWrite); event.set Остальные вначале делают проверку на if AtomicCmpExchange(FWrite, 0, 0) > 0 then ждем сигнал event
и далее разруливаем TMultiReadExclusiveWriteSynchrinizer

Если не получится или вылезут подводные камни - видимо придется таки переходить на FireBird.

Все большое спасибо за участие и советы !

Большое спасибо ! Попробуем !

авторпосле слов - сreate table/drop table - остается только ставить диагноз творцу

Вы думаете, что create/drop table будет из-за того, что так хочется моей правой ноге ? Нет, все очень внимательно продумывалась и это нужно в силу ряда обстоятельств. И я скажу больше - некоторые большие "справочники" будут в отдельных базах данных т.е. в отдельных файлах, да ) И работа с ними будет через ATTACH DATABASE. Так надо )

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

Читаем это:

авторYour sqlite3_step, sqlite3_prepare and some other calls may return SQLITE_BUSY or SQLITE_LOCKED. SQLITE_BUSY usually means that sqlite needs to acquire the lock. The biggest difference between the two return values:

SQLITE_LOCKED: if you get this from a sqlite3_step statement, you MUST call sqlite3_reset on the statement handle. You should only get this on the first call to sqlite3_step, so once reset is called you can actually "retry" your sqlite3_step call. On other operations, it's the same as SQLITE_BUSY
SQLITE_BUSY : There is no need to call sqlite3_reset, just retry your operation after waiting a bit for the lock to be released.

Т.е. возможны два вида ошибок у TQuery.Prepare, TQuery.Open, TQuery.Next и DataBase.StartTransaction/Commit. И в одном случае нужно переоткрыть запрос, а в другом пытаться еще несколько раз по таймеру. Если же самому управлять тем как потоки читают/пишут в базу можно полностью, с гарантией 100% исключить проблемы с busy/locked и не контролировать эти ошибки везде в коде где идет работа с базой.

авторЖесть... Еще больше уверен, что нужен толковый архитектор.
Либо это саботаж.

Вы понятия не имеете о специфике задачи, а предлагаете архитекторов, этого не надо. Вопрос был про многоуровневую синхронизацию потоков. Вы в курсе как это сделать наилучшим образом ? Нет ? :-)

авторНет никакой "проблемы" с busy/locked, это ШТАТНОЕ поведение, а не ошибки. И это поведение позволяет продолжить вычислительный процесс, а не перевести в тупое состояние ожидания доступности базы. Ты, если и реализуешь свой "диспетчер", в итоге в придешь к тому же самому (в лучшем случае).

Может и нет если работать с sqlite api напрямую. Но мы работаем через LiteDac/TDataSet, а для TDataSet это "штатное" поведение не является штатным.

Вообще вопрос был про многоуровневую синхронизацию потоков. Sqlite или нет - не имеет значения. Кто-то кроме X-Cite знает как это сделать ? Советчики архитекторов и учителя работать с sqlite не нужны :-)

Спасибо ! Попробуем !