WCF: Per-Call and Per-Session services...need convincing that Per-Call is worthwhile
Posted
by mrlane
on Stack Overflow
See other posts from Stack Overflow
or by mrlane
Published on 2010-03-30T02:05:22Z
Indexed on
2010/03/30
2:13 UTC
Read the original article
Hit count: 655
wcf
Hello all.
We are currently doing a review of our WCF service design and one thing that is bothering me is the decision between Per-Call and Per-Session services. I believe I understand the concept behind both, but I am not really seeing the advantage of Per-Call services. I understand that the motivation for using Per-Call services is that a WCF services only holds a servier object for the life of a call thereby restricting the time that an expensive resource is held by the service instance, but to me its much simpler to use the more OO like Per-Session model where your proxy object instance always corrisponds to the same server object instance and just handle any expensive resources manually.
For example, say I have a CRUD Service with Add, Update, Delete, Select methods on it. This could be done as a Per-Call service with database connection (the "expensive resource") instanciated in the server object constructor. Alternately it could be a Per-Session service with a database connection instanciated and closed within each CRUD method exposed.
To me it is no different resource wise and it makes the programming model simpler as the client can be assured that they always have the same server object for their proxies: any in-expensive state that there may be between calls is maintained and no extra parameters are needed on methods to identify what state data must be retrieved by the service when it is instanciating a new server object again (as in the case of Per-Call). Its just like using classes and objects, where the same resource management issues apply, but we dont create new object instances for each method call we have on an object!
So what am I missing with the Per-Call model?
Thanks
© Stack Overflow or respective owner