Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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.
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.