WCF Persist OperationContext with DurableService RRS feed

  • Question

  • Hello,

    Is it possible to persist the Operation Context?  I ask because while storing the operation context as a private member of the service works well, it only works while there is constant communication between the client and service (I believe that the connection is dropped after a minute or so). 

    I need to save the Operation Context of a particular client as other clients connecting to the service will be making heavy use of it but I can't guarantee that messages will be sent within a certain time frame.
    I could have one client periodically message the service to keep it alive but this feels sloppy so I am looking for another way.

    Any ideas?

    Thank you.

    Friday, January 10, 2014 9:17 PM

All replies

  • Hi 

    First of all this class is not designed for serialization,

    Operation context are part of Service Instance and created either per call basis or per session basis depending on setting,  If you share elaborated requirement them probably someone may be able to suggest some different design

    Thanks Ashwini 

    Saturday, January 11, 2014 6:11 AM
  • Hi,

    Thanks for your reply, I was fairly certain the operation context was not serializable though I was hoping that perhaps there was something I could serialize that would enable me to re-establish the connection on the Server side.

    I am using a custom IInstanceContextProvider that implements session sharing between clients, which works well as long as there is constant communication between the service and a client.

    The ideal solution would be a way to emulate a WCF data service except the service must get the data from the thick client as the service itself does not have access to the set of local databases.  This detail would largely go un-noticed by the thin clients.

    Thank you.

    Saturday, January 11, 2014 3:06 PM
  • I think that you should go with a very simple path , just increase the session and inactivity timeout of your service and you will effectively achieve the same goal , here is a link that may help you

    Monday, January 13, 2014 5:05 AM
  • That would be nice, but like I said in my original post, I cannot guarantee a finite inactivity period.

    For example lets say I gave the session/inactivity timeout a timespan of 1 hour it is still possible that no client has communicated with the service within that time frame, in-fact it could be days before anyone has messaged the service yet it should remain open.

    I'll try explain a little more about my current situation.

    We have an existing application and database that is installed on our customers local machines as a standalone product.  We are trying to evolve the software by providing a set of thin clients; Apps for Android, iOS, and WinRT and the web.  To do this we decided to construct a WCF Service that will pull data from any one of the thick clients installed alongside their respective databases up into the service which is exposed over the web then out again to the thin client that requested the data.

    Here is a shoddy ASCII diagram of the architecture

    Thick Client = [T]
    Thin Client = [t]
    Shared Session Service = [S]

    [T] <--------|
    [T] <--------|--->[S]<-------->[t]
    [T] <--------|

    Here the thin client makes a request that is sent to the service, the service uses a pre-established call back to the thick client to forward the request for the data, the data is returned to the service and then finally returned back to the thin client.  Essentially the service is nothing but a proxy to the thick client and if we could eliminate the middle-man-type service all together we would but we don't see how we could considering we cannot host web services on our end client machines.

    I am looking for any way to improve this architecture and make the development of these services much easier with the given constraints.  That includes the timeout problem.  Another developers approach to implementing this architecture would be interesting to see and perhaps learn from.

    Thank you.

    Monday, January 13, 2014 4:49 PM