Home/ Questions/Q 606879
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T17:18:03+00:00

I am to design a webservice using WCF that yields methods that don’t require

  • 0

I am to design a webservice using WCF that yields methods that don’t require a session (like static calls, eg: giving back some information about the webservice itsself) and other methods that require a session.

furthermore, the session based methods are using Workflows that are supposed to be able to be changed at runtime.

my current design would look like this:

there is a singleton service that runs in IIS that handles all the per call methods which also works as a host for the session based services. that way the singleton class knows about all the sessions and can halt the running workflows to exchange them.

is this a good/possible design choice?
is this a common scenario that uses a common design?
would be happy about any reading hints as the msdn help wasn’t such a help to me.

thanks for your answers
-redoced

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Using a singleton WCF service class is almost never a good idea – unless you really have just one single (physical) resource which you want to protect from concurrent access, it doesn’t really make sense.

    Because: either it’s not multi-threading capable, but in this case, it becomes a huge bottleneck – requests are handled strictly sequentially – one after another. Not very good for performance.

    Or then you need to make the whole service multi-threading aware – and let me tell you, making this properly, safely, and efficiently isn’t for the faint of heart. It’s really really hard to get this right, and make it perform well.

    I really don’t see any need for this, at all.

    • leave you "static" message calls (as you call them) be per-call services – those are easy to program, work well, perform well, never cause any multithreading issues

    • those few service calls (hopefully!) that do require a session – put them on their own service endpoint(s), make them per-session, use the "SessionId" in your session to identify them. It’s a bit more work than per-call – but still nowhere near as complicated and error-prone as multi-threaded programming

    Resources for WCF sessions:

    Resources for WCF durable services (that persist their state between calls):

    Resources for WCF Workflow Services:

    • 0