How to be like COM+ (pooling)
E. Nierop
hi,
COM+ has an object pool. As soon as a software client uses CoCreateInstance
it agregates the object, and correctly written (if the object is correctly
written i.e. it implements iobjectpool and is MTA), it can put the object in
the pool.
I was using aggregate_blind to the unknown pointer, however, the release was
not dealt with within the aggregating class but at the aggregated interface
implemenation, so IObjectPool::OnDeactivate, never could be reached.
Is there a way to reach this using aggregation? (The ATL sample at MS
support, was followed by me, but this obviously could not be used to
'emulate' com+)
http://support.microsoft.com/kb/173823
Brian Muth
technique for incorporating COM objects where there is no source code
available, otherwise it is a rarely used feature. (I don't think I've used
it ever in 12 years of DCOM programming).
If you are looking for features of COM+, why not just use Component
Services? It's been part of every Windows operating system since Win2000, so
I wonder about the motivation to re-implement this....
Brian
"E. Nierop" <som...@nomail.invalid> wrote in message
news:u5d04Qcc...@TK2MSFTNGP04.phx.gbl...
E. Nierop
"Brian Muth" <bm...@mvps.org> wrote in message
news:7C7F0918-E9C2-4D78...@microsoft.com...
> What is your ultimate goal here? Recall that aggregation is a useful
> technique for incorporating COM objects where there is no source code
> available, otherwise it is a rarely used feature. (I don't think I've used
> it ever in 12 years of DCOM programming).
>
> If you are looking for features of COM+, why not just use Component
> Services? It's been part of every Windows operating system since Win2000,
> so I wonder about the motivation to re-implement this....
This is for example, because clients keep on registering regsv32 instead of
using the SETUP.
> Brian
>
Brian Muth
> This is for example, because clients keep on registering regsv32 instead
> of using the SETUP.
>
I have no clue how this is related to object pooling and aggregation.
An MSI file that is used by SETUP can be constructed so that all the
appropriate registry settings are made, just as if regsvr32 was called.
Can you clarify your goal?
E. Nierop
To make a better object model using a static class factory.
If the factory also could use cocreateinstance it would be doable as well.
Brian Muth
>> Can you clarify your goal?
>
> To make a better object model using a static class factory.
> If the factory also could use cocreateinstance it would be doable as well.
A better object model that what???? The COM model already supports a
singleton class factory.
Your second statement makes no sense to me whatsoever.
Unless you can be more articulate about what problem you are facing and what
goal you are trying to achieve, I don't think anyone here can help you.
Regards,
Brian
E. Nierop
>
>>> Can you clarify your goal?
>>
>> To make a better object model using a static class factory.
>> If the factory also could use cocreateinstance it would be doable as
>> well.
>
> A better object model that what???? The COM model already supports a
> singleton class factory.
What do you mean with that? I'm not aware of that, not in the world of
scripting (the clients of my COM object) except for the (IDL)[appobject]
attribute that only VBA and VB6 look at.
> Your second statement makes no sense to me whatsoever.
Let me clarify.
My COM ojbect, is used in a scripting context.
Set blah = CreateObject("blah.project")
Behind creation exists counting the number of instances allowed (because of
a license model)
So, if I can hold that count in a better way, I can on a pro-active way
instead on a 'fail on try' base while CreateObject is being called.
So my target is:
Set Blah = myappinstance.NewBlahProject
why myappinstance is a global/static (singleton) instance and responsible
for the object instance count.
Since COM+ holds the number of instances, I have to 'hack' it, using
IObjectPool and a static DWORD variable, and an 'on error'.
Brian Muth
This is much clearer, thank you.
I strongly suggest that you use containment rather than aggregation as your
approach. This means authoring a COM class object that the scripting clients
can access without a limit on the number of instantiated objects. Each COM
object will attempt to instantiated one of the limited licensed COM objects
internally, and will return the appropriate ERRORINFO object if it fails to
do so. The IDispatch interface that must be implemented for scripting
clients can be trivially implemented by simply forwarding the calls to the
internal COM object's IDispatch interface.
I think there is a very simply solution at hand.
Brian
"E. Nierop" <som...@nomail.invalid> wrote in message
news:#kGnVQCd...@TK2MSFTNGP05.phx.gbl...