Головна сторінка
Top.Mail.Ru Яндекс.Метрика
Форум: "Основна";
Поточний архів: 2002.12.23;
Завантажити: [xml.tar.bz2];

Вниз

Прошу майстрів проконсультувати по складному питанню Знайти схожі гілки


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 методи, які таким способом, швидше за все не передаси.
Заздалегідь вдячний.
PS Компоненти 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 процесів для звичайної робочої станції. Виграшу в швидкості ти так точно не отримаєш. Але, можливо, задача того вимагає.



сторінки: 1 вся гілка

Форум: "Основна";
Поточний архів: 2002.12.23;
Завантажити: [xml.tar.bz2];

Вгору





Пам'ять: 0.64 MB
Час: 0.052 c
14-74892
Zergling
2002-12-04 09:19
2002.12.23
Движок для вимови тексту російською


6-74881
DarkRus
2002-10-25 16:34
2002.12.23
Download з інтернету


3-74614
Ігорка
2002-12-04 17:45
2002.12.23
ADOQuery і кілька параметрів з однаковими іменами


1-74741
Tik
2002-12-10 21:41
2002.12.23
StringGrid & File


14-74913
Vopros
2002-11-29 11:16
2002.12.23
Начебто все хорошо.Но така ж.па.





африкаанс албанський арабська вірменин азербайджанець баскський білоруський болгарська каталонський Китайська (спрощене письмо) Китайський традиційний) хорватський чеська данську мову нідерландський Ukranian естонець Філіппінська фінську мову французький
галісійська грузинський німецький грецький гаїтянський креольський давньоєврейську хінді угорський ісландський індонезієць ірландський італійський японський корейський латиська литовець македонець малайський мальтійський норвежець
перс полірування португальська румунський російська сербський словацький словенський іспанська суахілі шведську мову тайський турецька український урду в'єтнамський валлійський ідиш бенгальський боснійський
кебуано есперанто гуджараті хауса хмонг ігбо яванський каннада кхмерская Лао латинь маорі маратхі монгольський непальська панджабі сомалійський тамільська телугу йоруба
зулуський
Англійська Французький Німецький Італійський Португальська Русский Іспанська