Preventing multiple connections to a COM object
Randy Sales -- rsc@halcyon.com
Tuesday, September 17, 1996
Environment: MSVC 4.1, NT 3.51
This is actually a COM question but I am implementing my COM
objects using MFC (and CCmdTarget) and I felt the the answer
might be different using MFC than it would be using generic C++.
So here goes.
Is there a simple way to prevent more than a single connection to
an instantiated object through the same interface?
An example: An object is instantiated using interface ITry.
The client that instantiated the object passes a pointer to
the objects IUnknown interface to another potential client.
The potential client becomes a second client to the object by
calling IUnknown->QueryInterface() with the interface ID for
ITry. So now, two clients are connected to the same object
through different copies of the same interface. This means
that one client can make calls on its copy of ITry and modify
data within the object that will in turn potentially modify
how the object responds to the other client. In some
applications this is desirable. In mine, it is not. I do not
want more than one client at a time attached to the object
through a particular interface.
Any guidelines on literature that covers this type of
information would be greatly appreciated. As would any
specific suggestions.
Randy Sales
--
RS Consulting
1521 1/2 Cedar Street
Everett, WA 98201
Phone 206-259-1056
Fax 206-259-1315
email rsc@halcyon.com
Stuart Downing -- stuartd@izzy.net
Friday, September 20, 1996
[Mini-digest: 2 responses]
Can you have Lock/Unlock methods in the interface you're
trying to protect, and return an error code (E_ITRY_LOCKED?)
when calling methods while the interface is locked? It does
mean one extra step that clients of the interface have to go
through before they can use it.
Perhaps there's a more standard OLE way to do this I'm not aware of.
ISingletonConnection anyone? :)
------------------------
Stuart Downing
Creative Solutions, Inc.
stuartd@izzy.net
----------
From: Randy Sales[SMTP:rsc@halcyon.com]
Sent: Tuesday, September 17, 1996 6:31 AM
To: mfc-l@netcom.com
Subject: Preventing multiple connections to a COM object
Environment: MSVC 4.1, NT 3.51
This is actually a COM question but I am implementing my COM
objects using MFC (and CCmdTarget) and I felt the the answer
might be different using MFC than it would be using generic C++.
So here goes.
Is there a simple way to prevent more than a single connection to
an instantiated object through the same interface?
An example: An object is instantiated using interface ITry.
The client that instantiated the object passes a pointer to
the objects IUnknown interface to another potential client.
The potential client becomes a second client to the object by
calling IUnknown->QueryInterface() with the interface ID for
ITry. So now, two clients are connected to the same object
through different copies of the same interface. This means
that one client can make calls on its copy of ITry and modify
data within the object that will in turn potentially modify
how the object responds to the other client. In some
applications this is desirable. In mine, it is not. I do not
want more than one client at a time attached to the object
through a particular interface.
Any guidelines on literature that covers this type of
information would be greatly appreciated. As would any
specific suggestions.
Randy Sales
--
RS Consulting
1521 1/2 Cedar Street
Everett, WA 98201
Phone 206-259-1056
Fax 206-259-1315
email rsc@halcyon.com
-----From: "CCCHIANG.US.ORACLE.COM"
Maybe there is a better way, but to me the simple way top of my head is to
control it through IUnknown::QueryInterface(). Maybe have a static variable
inside it, increment everytime a client asks for a certain interface. Now you
have can control how many clients you want to have.
Clarence Chiang
Dave Kolb -- sasdxk@unx.sas.com
Monday, September 23, 1996
[Mini-digest: 2 responses]
Basically your app should be SDI or MDI capable. Search MSFT MSDN for =
"COM SDI MDI" and you will find an article where it explains:
The application must create and initialize its ClassObject and call the =
RegisterClassObject API before yielding. Depending on the type of =
application, it will specify one of the following flags on its call to =
RegisterClassObject:=20
=B7 REGCLS_SINGLEUSE-old-style or new-style SDI application that can =
create only one object instance
=B7 REGCLS_MULTIPLEUSE-MDI application that can create multiple object =
instances
Now preventing another instance is another problem altogether...
Dave Kolb
PC Research and Development
SAS Institute Inc.
919-677-8000 x6827
-----From: "CCCHIANG.US.ORACLE.COM"
Maybe there is a better way, but to me the simple way top of my head is =
to=20
control it through IUnknown::QueryInterface(). Maybe have a static =
variable=20
inside it, increment everytime a client asks for a certain interface. =
Now you=20
have can control how many clients you want to have.=20
=20
Clarence Chiang=20
-----From: Randy Sales
Environment: MSVC 4.1, NT 3.51
Stuart and Clarence (see below),
Thanks Stuart, that looks like what I'll end up having to do. And, of course,
to protect the object, I'll have to check the lock every time on every function
entry before proceeding. I wanted to avoid this because of the additional overhead
(this interface will have a fairly highly throughput). I had hoped to find a
COM/MFC standard way of dealing with this but there doesn't appear to be one.
Clarence, I had initially intended to do exactly as you suggested but, on
further study, it appears the approach of limiting the number of interface
connections by modifying the behaviour of QueryInterface is in direct violation
of COM protocol. According to spec, if an object supports a
particular interface, QueryInterface is ALWAYS supposed to succeed when asked
for that interface. I suppose I could bend the rules as long as I never
distribute this object, but I'm giving up one of the primary reasons for using
COM in the first place, to make the object conform to a "public" standard and be
reusable without any special instructions, at least in terms of acquiring
supported interface information.
If anyone else knows of a solution that does not impact every call into the
interface, I'd really appreciate hearing about it.
Thanks guys for taking he time to respond.
Randy Sales
--
RS Consulting
1521 1/2 Cedar Street
Everett, WA 98201
Phone 206-259-1056
Fax 206-259-1315
email rsc@halcyon.com
| Вернуться в корень Архива
|