views:

320

answers:

1

Hi guys!

I'm working in a WCF project and we need to reuse some legacy components from vb6.

In the service, we need to mantain state for each user as we need to store one COM Interop object (per user) which is costly to construct. The project can grow in the future so it's possible we may need to use StateServer/SqlServer-based session storing.

By default, COM Interop objects are not serializable, any ideas on how to continue?

Thanks in advance.

+2  A: 

That is indeed a fun problem. You can't serialize the COM objects, so you are forced to either keep them per-session on the service, or you have to suffer the cost of creating them.

Normally, I would advocate a pure stateless server (as it allows the best scalability), but if the COM object is particularly expensive this may not be realistic.

To manage this with multiple servers, sticky load-balancing becomes the only option. This isn't ideal (it gets messy when you take servers down), but does at least allow you to scale out. But you might need a decent NLB to achieve this (perhaps an expensive F5).

I wonder if in this specific case perhaps the best option is to scale up? Fill the server with cores and RAM (on x64), and go for broke... of course, if the COM control only works on x86 this may not help.

Marc Gravell
Thanks Marc, I'll investigate on sticky NLB!
Max
Depending on the nature of your service, you may be able to split it so that the part that works with COM is separate from the rest. The COM part might be able to remain on x86 boxes. If that part doesn't use much memory, then 64-bit might not be required for it.
John Saunders
@John - I'm guessing it has to be doign *something* non-trivial for it to have enough initialization cost to worry about...
Marc Gravell
It manages a whole reservation process (travel app) and it has many other COM dependencies.I thinks it's pretty good solution to use sticky sessions!
Max