Клиент-сервеный режим работы
Хочу один раз создать COMОбъект не важно откуда, через регламентное задание или из формы по кнопке
и использовать его многоразово, чтобы не создавать COMОбъект, если он уже создан

Создаю COMОбъект и сохраняю его адрес в константу:

Константы.КонстантаСтроковогоТипа.Установить(ПоместитьВоВременноеХранилище(COMобъектЭкселя,Новый УникальныйИдентификатор));

А когда мне надо проверить есть ли уже созданный объект делаю:

COMобъектЭкселя    = ПолучитьИзВременногоХранилища(Константы.КонстантаСтроковогоТипа.Получить());

Проблема в том, что если запустить регламентное задание и из-под него прочитать адрес хранилища - он будет заполнен правильным адресом, а вот если получить значение из адреса, то результат будет Неопределено.

Подскажите пожалуйста как сделать так, чтобы фоновое задание увидело содержимое расположенное во временном хранилище?

Использовал изначально статью:
Хранение COM Объектов на Сервере ТонкогоКлиента
http://kb.mista.ru/article.php?id=787
Но в моем случае ПараметрыСеанса не подходят.

Почему не подходят параметры сеанса? Ты хочешь заюзать один COM объект для всех пользователей?

используй С# и веб-сервис :)

> Почему не подходят параметры сеанса?
пробовал. При создании на сервере инициалиирую
Но когда сеанс другой запускается, параметр сеанса опять неинициализирован

> Ты хочешь заюзать один COM объект для всех пользователей?
Да, для всех юзеров, для всех регламентных заданий

Ерунду придумал....
Создаю на толстом клиенте объекта, записываю.
А потом читаю его из веб-клиента на каком-нибудь андройде.
А потом на сервере на линухе.
И что имеем?

ДенисЧ, все под вендой, вебсервисы к COMобъекту обращаться не будут.

посмотрел на партнерском форуме всплывал подобный вопрос в 2010 году.

из 1С никто не ответил, закончилось высказыванием:
"Фоновые задания это разные процессы а COM-объект живет в адресном пространстве породившего его процесса"

но мне надо многоразово использовать один и тот же уже созданный COMобъект из пользовательского режима и из фоновых заданий...

(6) >но мне надо
Пуговичку на затылок.

Не взлетит. В общем случае фоновые и сеансы могут жить на разных серверах кластера и про друг друга не подозревать вообще. Максимум, можно попробовать - закэшировать в рамках одного сеанса через модули повторного использования.

Есть еще в глобальном контексте:

ПолучитьCOMОбъект(<ИмяФайла>, <ИмяКлассаCOM>)
Параметры:

<ИмяФайла> (необязательный)

Тип: Строка.
Имя файла, включающее полный путь.
<ИмяКлассаCOM> (необязательный)

Тип: Строка.
Имя класса COM, экземпляр которого должен быть создан или получен. Если расширение имени файла, указанное в первом параметре полностью идентифицирует класс объекта, то параметр может быть опущен.
Возвращаемое значение:

Тип: COMОбъект.


Проблема в том, что нужный мне COMобъект при инициализации загружает в память EXE файл. И при попытке к нему обратиться через ПолучитьCOMОбъект(ПутьДоФайла) одинес говорит, что Расширение файла неправильное...

Вообще DLL особо не выгружаются из процесса. Так, что повторное обращение минимально по времени. Для .exe проще использовать сервисы COM+
http://www.steeltrace.ru/details/articleid/22/регистрация-1с-com-компонента-для-работы-с-64-битными-приложениями.aspx

(0) гугли "синглтон"

(10) Нафига тут синглетон, если задача изначально нерешаема в общем виде?

Serginio1, спасибо посмотрю

Да, если бы в моем случае это был чистый COM то проблем не возникло, а тут получается аплликейшен

(0) Модуль с повторным использованием значений на время сеанса. Вот твоё решение.

в чем проблема создавать ком, когда он нужен?

(14) Соединение иногда идёт по 10-30 секунд. Не всегда это приёмлемо.

(11) с какого перепугу не решаема? у меня есть готовое решение работающее в рамках одного рабочего процесса, правда только на 8.1 тестилось.

(14) + 100500
Тем более, что речь идет о мелкософтофском екселе. Там такая тема - когда создается экземпляр олеобъекта и олесервер уже запущен - олеобъект цепляется к УЖЕ ЗАПУЩЕННОМУ экземпляру олесервера. А не создает новый.

Таким макаром - все уже украдено /*заложено в логику олесервера*/ до нас и ТС.

(17)чет я про ексель не нашел упоминания...

(6) >мне надо многоразово использовать один и тот же уже созданный COMобъект из пользовательского режима и из фоновых заданий...

Жесть. Готов спорить, ты не сможешь внятно обосновать это "нужно". Ты правда хочешь, чтобы сеансы ждали друг друга на этих вызовах?

В принципе, все решается. Например, через дополнительную ВК и DCOM. Но не нужно.

(15) хренассе бъект ((

на мисте новая традиция: каждую неделю новая тема про ComОбъект и как его хранить между клиентскими вызовами.

(20) Соедниение со скулем или 1с-ом.

(16) С того, что оно хочет не в рамках одного процесса.

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

(18) В (0) русским по белому написано "COMобъектЭкселя"

(21)+ да уж. v8: Жизнь Переменной до закрытия обработки

(25) ну да, я именов не читал.
тогда надо просто писать COMобъектЭкселя = ПолучитьCOMОбъект(<ИмяФайла>)

Еще можно запустить Эксель а к нему уже подключаться
как
http://www.cyberforum.ru/delphi-beginners/thread822393.html
GetActiveOleObject('Excel.Application');

а кто вообще спросил каким образом теоретически может жить экземпляр ком обьекта на кластере серверов 1с?

ведь реально рхосты выполняются на физически разных серверах, при чем возможно даже с разными операционками!

поэтому хотелка автора в общем случае - бред!

(29) Вообще-то я об это твержу с самого начала....

эксель в имени просто как пример приведен.
надо запускать http://winscp.net/eng/docs/library

там при поднятии
Session    = Новый COMОбъект("WinSCP.Session");
тут опредеяем настройки и делаем
Session.Open(Структура.SessionOptions);

в процессах появляется WinSCP.exe

т.е. я хочу один раз поднять его и дальше юзать

Также понятны доводы почему этого нельзя сделать стандартно из 1С
Надо пробовать предложенные сторонние средства, были бы примеры по-подробнее

(29) отдельный сервер под ком ))

Ок
спасибо всем кто принял участие в обсуждении

А почему нельзя для каждого юзера инициализировать ?
Ну подождет он 20 сек при инициализации, а потом сможет пользоваться целый день

(35) не сможет, по тому, что 1с не содержит в себе средств с помощью которых можно гарантировать что все запросы одной сесии будут исполнятся в одном рхосте. (что к слову сказать правильно)

(36) если хост один, то очень даже может

На самом деле, проблемы с созданием одного объекта на все процессы никакой нет. Только делать это нужно внутри самого объекта, и жить он должен в отдельном процессе - тогда в каждом процессе будут создаваться только заглушки для передачи данных, но обмен с объектом будет очень медленный.
Если же мы хотим передать ссылку на COM-объект из одного процесса в другой, то в общем случае, мы получаем кучу проблем - если COM-объект живёт в адресном пространстве одного процесса, то его методы могут вызываться напрямую, а из другого процесса эти методы должны вызываться через заглушки - также нужна гарантия, что процесс не завершится, иначе все остальные получат ссылку на того, кого уже нет.
В случае 1С никто не даст гарантию, что процесс, создавший объект не будет завершён, а передачи объекта из одного процесса в другой просто нет.

>>>а из другого процесса эти методы должны вызываться через заглушки

не правда, из одного процесса можно напрямую использовать любую незащищенную память любого процесса. На сколько я понимаю так работает например "снегопат"

(39) И как предполагается использовать память, если физическая память проецирована в разные адресные пространства двух процессов.
Понятно, что можно сделать копирование данных, например есть даже WM_COPYDATA, но осознанную информацию получить будет проблематично - например, если в объекте где-то есть ссылка на другой блок памяти, то другому процессу такая ссылка ничего не скажет - адреса-то разные.

(40) что-то типа GlobalDosAlloc, на память не помню, в msdm  читал описание как можно помещать свай код в память чужих процессов. (разумеется если прав хватает)

(3) тебе ж сказали, используй С# и веб-сервис и твоя хотелка удовлетворена.

(41) Таки и WriteProcessMemory никто не отменял.
А про CreateRemoteThread я вообще молчу.
Только чем это поможет COM-объекту, который живёт и работает в памяти одного процесса и ничего не знает про другие, а для RPC-вызовов должна использоваться очередь событий того потока, в котором живёт сам объект (также не забываем, что в одном процессе может быть несколько потоков, у которых память общая, а стеки находятся в разных местах).

(38) (39) Читайте про DCOM.

Я так и не понял что в итоге -
у меня есть com объект долго инициализирующийся - порядка 20 сек. Хотелось бы его сохранить, хотя бы для одного пользователя.
На данный момент как в 1С делать ?

(45) в 8.2 - хранилище значения и при получении проверять на живость.
В 8.3 - функция в общем модуле с кешированием результатов.

(46)
На живость - Неопределено, или попытка выполнить метод ?

Или типЗнч

(47) Сначала неопределено, потом вызов метода в попытке.

http://infostart.ru/public/93643/

(49)
Ок, спасибо !

(50) Вот-вот и я тоже вспоминал, что COM+ - это как раз то, что нужно - причём всё делает сама система - просто нужно настроить.