Прошу мастеров проконсультировать по сложному вопросу

← →
Yr2 (2002-12-13 14:13) [0]

Есть необходимость передать указатель на заданный компонент из одного приложения, написанного на Delphi в другое приложение (процесс). Так, чтобы этот второй процесс мог тоже "видеть", то есть работать с данным компонентом (через указатель на него). Например, я использую в первом приложении компонент TDatabase, то есть, выставляю ему свойства и открываю. В другом процессе (который я открываю, естественно, в другой зоне памяти) я не хочу повторно создавать и запускать второй TDatabase. Хотелось бы передать только указатель на него и дальше подключать соответствующие TTable, TQuery и т.д.
Думаю, что сделать это можно следующим способом:
- создать COM-объект и интерфейс на него ImyDatabase=interface(IUnknown). Причем interface должен повторить все проперти и функции известного компонента TDatabase.
- создать свой компонент TxxxDatabase, который сам ничего не делает, а только ссылается на интерфейс ImyDatabase и "выставляет" свойства и методы ImyDatabase как свои.
При разработке второго приложения разработчик кидает на форму TxxxDatabase и это (по моему мнению) должно позволить другим компонентам формы (TTable, TQuery) "увидеть" и подключиться к этому TxxxDatabase.
Таким образом, я предполагаю, открыв в одном процессе TDatabase один раз и запустив COM-объект дать, возможность другим процессам работать с ним же.
Реально ли такое? У меня есть подозрение, что компоненты, подключенные к TDatabase запускают не только public методы, но и privat методы, которые таким способом, скорее всего не передашь.
Заранее благодарен.
P.S. Компоненты TDatabase, TTable и TQuery были приведены для примера. Если быть точным, то мне нужно сделать это с компонентом TOraSession, чтобы в других процессах подключить к ней (сессии) TOraQuery.

← →
Anatoly Podgoretsky (2002-12-13 14:25) [1]

Смысла нет, разные адресные пространства, ищи другие методы

← →
Yr2 (2002-12-13 15:05) [2]

To Anatoly Podgoretsky
Смысл есть в том, что если это удастся сделать, то 30 открытых процессов будут использовать только одну сессию к БД, а не 30!
Я понимаю, что это разные адресные пространства. Но ведь, как это не смешно звучит, память-то в компьютере одна?! И сама Windows "имеет доступ" к любому адресу. Вот из этого я и исхожу.
Кроме того interface()_s как раз и были созданы для обмена информацией между разными процессами, что я и думаю использовать.

← →
Игорь Шевченко (2002-12-13 15:22) [3]

Yr2 © (13.12.02 15:05)

Нету смысла. Даже не пытайся. В твоем случае может помочь сервер приложений или MIDAS.

← →
Yr2 (2002-12-13 16:20) [4]

To Игорь Шевченко
Я подумывал о MIDAS. Но "есть мнение", что MIDAS работает медленно и после десяти коннектов к нему начинает "тихо умирать".
У меня предпоглагается, что на машине будет запущено до 100 процессов, коннектящихся к одной и той же БД. Предположим, что такой компонент, что я описал в письме был создан (!?!). У меня все-же есть сомнение, что независимые процессы смогут корректно с ним работать (все одновременно).
Что касается сервера приложений - то это для меня вариант "темный" (не с точки зрения эксплуатации, а с точки зрения его разработки). Кто-нибудь делал сервер приложений, который "выставляет" делфийский компонент, например TOraSession?
Это ведь тоже нужно в этом сервере повторить все свойства и методы компонента?
Если кто-то делал, подскажите, пожалуйста, ссылочку на исходники.

← →
Polevi (2002-12-13 16:25) [5]

>MIDAS работает медленно и после десяти коннектов к нему начинает "тихо умирать".
у меня 200 коннектов и умирать он похоже не собирается

← →
Yr2 (2002-12-13 20:00) [6]

To Polevi
А можно узнать, в чём заключается Ваша система на MIDAS, а еще лучше получить "кусочек исходничка"?

← →
yaJohn (2002-12-13 20:14) [7]

>Таким образом, я предполагаю, открыв в одном процессе
>TDatabase один раз и запустив COM-объект дать,
>возможность другим процессам работать с ним же.
Плохие новости. Так можно сделать, конечно. Это уже даже сделано. И называется именно МИДАС. И почему Вы полагаете, что это будет один COM обьект, а не по штуке на каждого клиента? Это более чем спорное утверждение.
Ну и кроме того, как Вы собираетесь синхронизировать запросы асинхронных процессов для выполнения их в одной сессии? Просто запрос внутри TThread - достаточно нетривиальная штука, не говоря уже о транзакциях.
Создав RemoteDataModule можно средствами дельфи сгенерировать компонент имеющий функции описанного Вами TxxxDatabase. Т.е. компонент ставится на стороне клиента, но все вызовы переадресуются к RemoteDataModule.
Мидас - продукт, несомненно, спорный. Таких граблей как там я еще не встречал, разве что в ADO. Но Ваша задача - именно из этой области и боюсь решить ее лучше чем это сделано в мидас будет не просто.

Почитайте статьи по мидас на этом сайте, думаю, найдете массссссу интересного. И не стоит полагаться на "есть мнение" ;)

← →
Yr2 (2002-12-13 20:55) [8]

To yaJohn
Синхронизация запросов асинхронных процессов для выполнения их в одной сессии - действительно вещь тяжелая. Надеюсь, что MIDAS её решает корректно. И делает это с помощью дублирования COM-объекта для каждого процесса. Но, если это так и я создал компонент ТСессия в RemoteDataModule, то означает ли это, что 30 процессов с "помощью" MIDASа откроют 30 сессий к БД? Если это так, то 30 процессов на одной машине, помноженные на 100 одновременных пользователей дадут 3000 коннектов к БД! а это уже её "напрягает"...
А по-поводу "не стоит полагаться на...", хочу заметить, что данный сайт (мною уважаемый) и есть сбор мнений. Кому доверять, кому нет - дело почти интуитивное...

← →
Fantasist (2002-12-14 00:54) [9]

> Таким образом, я предполагаю, открыв в одном процессе
> TDatabase один раз и запустив COM-объект дать,
> возможность другим процессам работать с ним же.

Действительно так можно сделать. Только не надо пытатся это абстрагировать, чтобы сделать так, как-будто работаешь с обыкновенным TDatabase. Надо создать свой OLE сервер, тогда клиенты смогут к нему подключаться, и надо для него определить вполне конкретный интерфейс. Хотя, конечно, можно (и даже, скорее всего, нужно) написать компонент-обертку над этим интерфейсом, так чтобы этот компонент и сам подключался. Тогда почти можно имитировать TDatabase.
Только ты действительно хочешь, чтобы все твои 30 вызовов к БД тормозились проходя через твой сервер по очереди?

"Всякую проблему дизайна можно решить введением дополнительного абстрактного слоя, за исключением проблемы слишком многих абстрактных слоев". С MIDAS как раз эта проблема. Ради удобства и универсальности были пожертвованны простота и эффективность. Хотя действительно это дает возможность быстро и удобно разработать multi-tier.

← →
Yr2 (2002-12-14 16:10) [10]

To Fantasist
> Только ты действительно хочешь, чтобы все твои 30 вызовов к БД тормозились проходя через твой сервер по очереди?

- Да, это допустимо. Главное, чтобы
а) все мои 30 windows-процессов "продолжали жить своей жизнью самостоятельно", то есть, если в этом процессе в текущий момент нет работы с базой данных, то пользователь мог всё-равно там работать (смотреть, нажимать кнопки и т.д...)
б) количество сессий от 30-ти процессов было не 30, а всего 1!
(подразумевается, что все коннекты открыты под одним и тем же логином/пассвордом)

> Хотя, конечно, можно ... написать компонент-обертку

- Я это понимаю. Но только у меня есть сомнение (как я написал в первом письме), что через эту обертку можно будет передать private методы.

← →
Набережных С. (2002-12-14 19:36) [11]

На сервере - DataModule c DataBase. Добавляешь RemoteDataModule с tmSingle и MultiInstance, на котором DataSets, подключенные к этой DataBase. На клиенте - ClientDataSet. Все.
Ну хочется человеку!

← →
Sergey Masloff (2002-12-14 20:33) [12]

Yr2 ©
Все же MIDAS будет хорошим решением. На Win2000 имеется возможность использования COM+ с организацией пула соединений. То есть сессий будет столько сколько активных запросов к БД.

Кстати, а что OraSession позволяет из двух потоков 2 запроса ОДНОВРЕМЕННО запустить? ;-)

← →
Yr2 (2002-12-14 22:19) [13]

To Набережных С.
Похоже, что MIDAS действительно позволит решить мою задачу. Спасибо, так и делаю. Только у меня вместо TDataBase используется TOraSession. Причем она одна на все коннекты к серверу приложений, а TOraQuery открываются (дублируются)на сервере при каждом новом коннекте клиента.

To Sergey Masloff
> То есть сессий будет столько сколько активных запросов к БД.

- Мне как раз и НЕ нужно, чтобы новые сессии открывались при каждом новом коннекте.
Но, это имеется ввиду, что все клиентские приложения, запущенные на одной клиентской машине под одним и тем же логином/пассвордом должны работать через одну и ту же сессию, открытую в сервере приложений. Приложения, запущенные на другой машине другим юзером (под другим логином) должны открыть новую сессию в сервере приложений. Таким образом планируется достигнуть цель: сколько юзеров, столько открытых сессий к базе, без умножения на количество запущенных приложений одним юзером.
> а что OraSession позволяет из двух потоков 2 запроса ОДНОВРЕМЕННО запустить? ;-)

- Похоже, что да... это предстоит тщательно проверить. Но хелп сообщает:
TOraSession.ThreadSafety property ThreadSafety: Boolean; Description Allows to use the OCI in multi-threaded environment. ThreadSafety property must be True before any non blocking fetch of rows or SQL statement execution takes place. See Also TOraDataSet.NonBlocking TOraSQL.NonBlocking

← →
Набережных С. (2002-12-14 22:58) [14]

Раз допустима многопоточность, то нет смысла использовать Single-модель. Выбирай STA или MTA. Или комбинируй.
Любопытно, что за задача такая? Как может быть, что с одной машины - одновременно несколько разных коннектов? Честно говоря, не улавливаю:)

← →
Fantasist (2002-12-14 23:33) [15]

> - Я это понимаю. Но только у меня есть сомнение (как я написал
> в первом письме), что через эту обертку можно будет передать
> private методы.

В каком смысле? Это разграничение доступа никакого отношение к интерфейсам не имеет. Надо просто поработать над исходником того же TDatabase, таким образом, чтобы все его поля и методы стали бы реализацией некого вашего интерфейса, которым вы его и снабдите.

> Как может быть, что с одной машины - одновременно несколько
> разных коннектов?

Это наверное такой multi-tier. Все эти 30 процессов являются серверами и все висят на одной машине вместе с БД. А клиенты подсоеденяются к одному из этих 30 серверов для выполнения какой-то спецефичной функциональности. :) Машинка, небось, снабжена десятком сетевых карт. :)

← →
Yr2 (2002-12-14 23:46) [16]

To Набережных С.
Попробую описать задачу, но упрощенно.
На клиентской машине запускается 30 applications, (то есть 30 отдельных windows-процессов). Все эти приложения запускаются кучей из одного родительского под одним и тем же логином/пассвордом. Каждое из этих приложений делает внутри себя свою "черную" работу с TOraQuery длительное время. Как этого достигнуть? Да очень просто: кидай на форму каждого приложения одну сессию, один квери и связывай их между собой! Это обычная практика, только вот в этом случае сколько таких приложений, столько и открытых к БД сессий! А мне нужно, чтобы вся эта "куча" приложений работала только с одной единой на всех сессией. Повторяю, при этом все эти приложения существуют в разных адресных пространствах windows. На другой машине будет запущена своя "куча" приложений под другим логином, поэтому для второй кучи должна быть открыта уже вторая сессия к БД (но 30!)

← →
Набережных С. (2002-12-15 00:06) [17]

Ну что же, всякое бывает... если ты уверен, что эту кучу процессов нельзя заменить кучей потоков, которая, кстати, обошлась бы несколько дешевле. Да и многовато это - 30 процессов для обычной рабочей станции. Выигрыша в скорости ты так точно не получишь. Но, возможно, задача того требует.

Прошу мастеров проконсультировать по сложному вопросу Найти похожие ветки