) AServer COM server, in my application. IList is refering to AN internal data list that is created in AServer. The data list is populated based on the username I passed into IList. Now, if I run ANOTHER instance of my application with different username, the IList in my 2nd app still refer to the 1st data list... populating the 1st data list with ''2nd user data items'', resulting the IList in my two apps have the same content.
I am thinking of initiating another AServer for my 2nd app, so the 2nd IList refer the list from the 2nd AServer. But I''m beginner to COM/OLE.. any steps to follow? Or other workarounds?
Initiating another COM server
Author
I''m using an IDispatch-derived interface (e.g.) IList, from (e.g. again ) AServer COM server, in my application. IList is refering to AN internal data list that is created in AServer. The data list is populated based on the username I passed into IList. Now, if I run ANOTHER instance of my application with different username, the IList in my 2nd app still refer to the 1st data list... populating the 1st data list with ''2nd user data items'', resulting the IList in my two apps have the same content.
I am thinking of initiating another AServer for my 2nd app, so the 2nd IList refer the list from the 2nd AServer. But I''m beginner to COM/OLE.. any steps to follow? Or other workarounds?
) AServer COM server, in my application. IList is refering to AN internal data list that is created in AServer. The data list is populated based on the username I passed into IList. Now, if I run ANOTHER instance of my application with different username, the IList in my 2nd app still refer to the 1st data list... populating the 1st data list with ''2nd user data items'', resulting the IList in my two apps have the same content.
I am thinking of initiating another AServer for my 2nd app, so the 2nd IList refer the list from the 2nd AServer. But I''m beginner to COM/OLE.. any steps to follow? Or other workarounds?
Make AServer an In-Proc server (DLL). Each process that uses the server will have it''s own copy of the list.
Author
quote:Original post by Solo
Make AServer an In-Proc server (DLL). Each process that uses the server will have it''s own copy of the list.
If AServer is an .EXE and I have no source code about it... how am I going to have it be DLL?
Sounds like the developer of the server you're using either forgot to support or decided not to support multiple clients. You'll need to check their documentation.
I know of no way to start a second instance of a COM server.
[edited by - Solo on July 9, 2002 10:35:12 AM]
I know of no way to start a second instance of a COM server.
[edited by - Solo on July 9, 2002 10:35:12 AM]
quote:Original post by Solo
Make AServer an In-Proc server (DLL). Each process that uses the server will have it's own copy of the list.
That's incorrect. An in-proc server merely means that each client process will have a copy of the server brought into it's local address space, but does not guarantee a different copy of the server is brought into each address space.
quote:
Sounds like the developer of the server you're using either forgot to support or decided not to support multiple clients
That doesn't sound like the case at all. Returning a reference to a singleton does not mean multiple clients cannot be supported, it means that all clients access the same class object, which is sometimes desirable. It's more likely that the developer wanted that behaviour for a reason.
DerekSaw: it sounds like the class factory's CreateInstance is handing out a reference to a singleton class object. Your options are:
i) change the class factory to hand out references to new objects every time it is called (mind this doesn't break assumptions that other clients rely on);
ii) create a new COM server modelled on the original, but with a class factory that does what you want;
iii) I can't think of a third option right now.
[edited by - SabreMan on July 9, 2002 1:11:08 PM]
quote:
An in-proc server merely means that each client process will have a copy of the server brought into it's local address space, but does not guarantee a different copy of the server is brought into each address space.
Yes, but each process will have a separate copy of any data allocated by the server (i.e. an internal list). Excepting shared memory of course.
quote:
That doesn't sound like the case at all. Returning a reference to a singleton does not mean multiple clients cannot be supported, it means that all clients access the same class object, which is sometimes desirable. It's more likely that the developer wanted that behaviour for a reason.
Except in this case the functionality of a singleton isn't desirable. And if IList is a singleton his using it in the way he describes in the post is likely not supported.
But yes, to be completely accurate I should have used "can" instead of "will" in my original post.
[edited by - Solo on July 9, 2002 4:43:44 PM]
Author
quote:Original post by SabreMan
iii) I can''t think of a third option right now.
Maybe the third option is to complete throw off the COM server, put more effort, spend more time, and obtain the list data manually.
Thanks.
quote:Original post by Solo
Yes, but each process will have a separate copy of any data allocated by the server (i.e. an internal list). Excepting shared memory of course.
A singleton would count as "shared memory".
quote:
Except in this case the functionality of a singleton isn''t desirable.
There is not enough context to know whether that is the case. If the original developer of the COM server made CreateInstance return a reference to a singleton, then there was probably a desire for that behaviour. Now DerekSaw has a desire for different behaviour, but that doesn''t necessarily invalidate the reasons for the original class factory serving-up a singleton. DerekSaw''s the only person here in a position to know why the server behaves as it does.
quote:Original post by DerekSaw
Maybe the third option is to complete throw off the COM server, put more effort, spend more time, and obtain the list data manually.
If you have the source code available, then you can probably use a lot of the existing code. All you need is a different creation policy.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement