tags:

views:

32

answers:

3

I have a large(ish) COM object that works as the back end of my PHP application. Every time i refresh the page, PHP creates a new object of the COM interface. This is however slow.

Is there any way to serialize/cache the COM object so that I can access the already initialized object? Or is there maybe some other workaround. I would also like to have control over which object belongs to which session.

Is this even possible using PHP? I'm even prepared to switch to another language to get this to work.

A: 

No - the com object exists outside the PHP memory space - you only PHP's decorator object within PHP.

C.

symcbean
+3  A: 

I doubt very much whether this is possible. COM objects are similar to connection resources in nature, which can't be serialized either.

The only idea that comes to mind is having a PHP process running constantly, having initialized the COM object, and other PHP processes communicating with that e.g. using memcache. PHP is not built for such long-lasting operations, though - not sure whether it would work well.

Here is an interesting question that I stumbled upon: PHP Daemon/worker environment

And about using PHP as a background process: Is it wise to use PHP for a daemon?

The most attractive way might be building a daemon in a different language that loads the COM object, and offers its services to PHP processes through sockets.

Pekka
A: 

The asier solution could be a COM proxy. The COM proxy server would expose the same COM interfaces to your PHP app. Each proxy object would redirect transparently to the underlying original COM object. The point of the proxy is to put the heavy COM object back into a pool/cache on release, so that new proxies can be created quickly in the future by recycling an COM object from that pool instead of creating a new one.

MSalters
This was what I was thinking about. How would it be implemented?
Pekka
Thank you for your answer. Do you know of any examples or tutorials on how to do something like this?
Tom
Each `CProxyComClass` would hold a pointer to a `COriginalComClass`. The class also has a `static` pool. Every interface `IFoo` implemented by `COriginalComClass` you implement on `CProxyComClass`. Every method `CProxyComClass::Bar` forwards to `COriginalComClass`, except for the `IUnknown` methods. `CProxyComClass::QueryInterface` must return interfaces of `CProxyComClass`, of course. `CProxyComClass::Release` is where the added value is: it returns the `COriginalComClass*` to the pool. The class factory should manage the pool, creating `CProxyComClass` from pooled `COriginalComClass`
MSalters