Is it really worth pooling WCF proxy clients, or is it better to instanciate a new proxy on every call to a given method?
By the way, does anyone have a pooling pattern for this kind of proxies which he/she is willing to share?
Share
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.
Is it really worth pooling WCF proxy clients, or is it better to instanciate a new proxy on every call to a given method?
By the way, does anyone have a pooling pattern for this kind of proxies which he/she is willing to share?
It is worth to cache
ChannelFactorybecause its construction is costly. Proxies generated by Add Service Reference (orsvcutil.exedirectly) do this in some scenarios (generally you must not build binding in code if you want to have this caching). If you buildChannelFactorymanually (you don’t use generated proxies) it is up to you to store it somewhere instead of initializing it every time you need it.Pooling proxies probably doesn’t make much sense. For stateless services the proxy creation should be fast (if you have cached factory). For statefull services you don’t want sharing proxy among multiple “clients”. There is also pooling on connection level itself. HTTP bindings use something called persistent connections by default. These connections can be reused by multiple proxies. Net.tcp and net.pipe bindings use connection pooling internally. It means that lifetime of the proxy doesn’t have to be the same as lifetime of the connection.