Здравствуйте.

Есть необходимость создать костыль сервис, работающий на удалённом сервере, который будет предоставлять довольно древнее NoSQL API к современной MS SQL базе данных. Именно сервис, потому что необходимо реализовать отличную от SQL схему блокировок строк таблицы, и кэширование, обеспечивающее более высокую производительность последовательного чтения записей, чем это даёт ODBC.
Хотелось бы использовать COM+, но я ни разу не пользовался этой технологией... Что выбрать, EXE или DLL сервер? Я слышал, что DLL COM+ может автоматически создать отдельный поток для каждого пользователя, и изолировать их друг от друга, но можно ли в таком случае пользоваться разделяемыми между потоками данными, такими как таблица блокировок или кэш?

Dimitry SibiryakovЕсли уже есть спецификация некоторого API, то выбора "как его реализовать" не остаётся:
его надо реализовывать описанным способом.

Или вопрос в том как организовать взаимодействие между реализацией API и подлегающим MS
SQL? Так это не в этот форум, поскольку опять же надо использовать строго фиксированное
API, представляемое MS SQL.


Нужно реализовать API Btrieve, чтобы очень старый софт мог работать через него с базой данных MS SQL. Софт обладает очень неприятной особенностью: если последовательное чтение записей (строк таблицы) происходит недостаточно быстро, то программа молча прекращает чтение, и отображает пустую таблицу - как будто ничего не было прочитано. Вопрос о том, как именно транслировать вызовы Btrieve в SQL запросы не стоит, вопрос в том, как организовать связь сервера и клиентов при помощи COM+.

Cerebrumимхо COM+ - мертворожденная технология, я бы не стал к ней прикручивать новый софт
COM+ не дает никаких преимуществ, по сравнению с голым RPC, весь маршалинг все равное придется делать руками (IDL и прочие радости), но тут, конечно, зависит от того, на чем собственно писать собираетесь, какие библиотеки использовать.

Опять же, имхо, если жесткий требований не стоит обеспечить COM совместимость, то я бы писал обычную службу, либо с собственным протоколом и логикой, либо что из современных популярных а ля SOAP.
Ну так COM+ вроде бы из коробки обеспечивает многопоточность, что довольно неплохо. Кроме того, мне в первую очередь важна скорость, скорость, и ещё раз скорость, так что текстовые протоколы основанные на XML мне вряд-ли подойдут...

Dimitry SibiryakovКакого сервера с какими клиентами?
Очевидно, между сервером где устанвлен MS SQL и клиентскими компьютерами. Да это прокладка, но она необходима для сетевого взаимодействия серверной части (которая обрабатывает блокировки и содержит кэш таблиц), и клиентской - той самой DLL с одной функцией.

Basil A. SidorovСам Btrieve - система управления записями: надёжные обновления, вставки, блокировки и всё такое.
Поверх этого Pervasive делал упрощённый SQL, но, убей меня бог, если я понимаю, как можно провернуть фарш назад и предоставить низкоуровневый доступ к записям через высокоуровневый SQL ...
Можно, например, читать таблицу из базы данных большими кусками в память, и уже с этими данными работать в рамках Btrieve API.

Basil A. Sidorov, нет, данные должны браться из таблицы SQL с помощью API Btrieve, и никак иначе.

Однако мне сейчас нужно написать многопоточный COM+ сервер с использованием ATL, и с возможностью использования переменных разделяемых между потоками.