Re: jointly MBV objects
Considering you've already implemented the maintenance code,
completely independently marshaling via MBV and recreating
the two objects in the other process should give you a single
proxy (e.g. your code as described already does that). Nothing
special to do on the MBV side. Same about in-process MBV
marshaling - both newly created copies will link to the existing
proxy object. A word of caution - your proxy and your lookup
singleton must be completely thread0-safe, even if your COM
objects are not free-threaded. That is because your internal
objects can still be accessed from multiple apartments, e.g.
multiple threads within the same process.
Note that you can put all necessary information in your
initial MBV marshaling packet, not just a simple ID. No need
for extra out-of-band communication between the copy and
the original object. Since this is the state of the internal object,
you'd ignore it if the object already exists in the new process.
I do see a problem of course if the state is quite big - you'll be
marshaling it twice for starters, but it may render the marshaling
packet prohibitively big as well. So your out-of-band idea may
not be that bad in such case... :)
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@mvps.org
MVP VC FAQ: http://vcfaq.mvps.org
=====================================
"Jason S" <jmsachs@gmail.com> wrote in message
news:1180727400.588407.279310@g4g2000hsf.googlegroups.com...
OK, I want to create a relatively lightweight COM abstraction layer
for a server that lives on another computer. (Please don't suggest
using DCOM; I can't get even a simple DCOM example to work between 2
computers & I have other reasons for needing to use my own network
protocol)
I have an architecture-related question for how to do "jointly marshal-
by-value", not quite sure how to ask it, but here's a thought
experiment.
There are 4 C++ classes CObj1, CObj2, CSrvProxy, and CLookup in an in-
process (DLL) COM server.
CObj1 and CObj2 are exposed to COM via interfaces IObj1 and IObj2.
CSrvProxy is not exposed to COM, but is reference-counted. CLookup is
not exposed to COM and is a single object in the DLL.
CObj1 and CObj2 represent objects in a hierarchy. They are flyweights
and the only state they contain is a pointer to a CSrvProxy (which
manages a connection to the server) and an identifier (ObjID) to
identify where they are in the hierarchy.
CSrvProxy contains cached state information from the server & is
responsible for updating/expanding that cache by communicating with
the server through TCP/IP; each CSrvProxy has a SrvID if there are
connections to multiple servers.
CLookup is a single object that is just a lookup table that maps
SrvID's to CSrvProxy pointers. (akin to a running object table)
If I want to marshal IObj1 or IObj2 to another apartment, I will use
marshal-by-value by serializing the SrvID (and hostname and port info)
and the ObjID. When I unmarshal the serialized data in the new
process, I will just use the ObjID, and obtain a CSrvProxy pointer
from the CLookup object; if a CSrvProxy already exists with the given
SrvID, then I will use it, otherwise I will create a new CSrvProxy
appropriately.
So if I have 2 objects IObj1 and IObj2 that are marshalled to another
apartment, then in the new apartment it creates the 2 objects there,
but only one CSrvProxy object.
Any problems with this approach? The only thing I can think of is that
there's no convenient way to pass along the cached state information;
I would have to use outside-of-COM techniques to get it from a
CSrvProxy in one apartment to another.