Multiple sessions

Is there any official guidance on spawning multiple MatterCentre sessions, so that web users aren't forced to share the API singleton? I've found it works okay if you're careful about what you use and don't want to scale it, but a session each seems a more natural fit, if it's do-able. Is this where Mattersphere needs to come in, though?

Server Side sessions is not a problem albeit not very thread safe, our data connection is currently being throttled to allow limited support for this scenario albeit succesfully. There is a connection option you can set to allow to keep the connection open which dramatically improves this. As to Mattersphere this is the way we are going to provide more server centric multi threaded n-tier based building blocks in the future.

Would this be one server-side session shared between multiple clients, or multiple OMS sessions? I was hoping that giving each user a session might reduce my reliance on a synchronised wrapper, and maybe scale better.
I've got DatabaseSettings.ConnectionAlwaysOpen set true, which sounds like the one. Do let me know if there's anything else I should be setting though.

Darren Baldwin was liaising with a 3rd Party whom was hammering our service when running in a service context and would be best to comment further, I know the settings you are using but not exactly sure on the errors and or issues that you are directly getting from a scale perspective, what sort of workload are you trying to put on this as there are some other services like OMSDTS that albeit limited to the same service layer process and import transactions from XML payloads and Webservices. Mattersphere would be the more appropriate logic for the future if wishing to host a core service platform.

Matter Centre wasn't designed to be run like this being a Client/Server application. In saying that we did have to run it in a similar fashion when we adapted it to run in the Microsoft test labs as we had to run without any user interaction and simulate more users than we had machines.To do this we had to spawn off multiple sessions as different users creating an Application Domain for each user spawned.Not for the faint hearted but possible and you may have to create another layer of abstraction to provide a shim function to call.Investigate AppDomain.CreateDomain for information in MSDN or online.Or wait for Mattersphere which is being designed to address this and many other scenarios.

The anticipated workload is light for OMS, just a handful of users mainly doing selects on trivial datalists & searchlists. My main concern is if one user starts a long-running operation (e.g. a 20 second search using a datalist), might it block the connection for others?
I've encountered the occasional “connection busy” error, but so far only when there's multiple concurrent users on a slow WAN link. I can pipeline the requests or even ditch the API to prevent this happening, but I'd rather spin up multiple OMS sessions if I can. It better reflects the reality of several people all doing their own thing, and it'll be easier to port scripted business logic written for the Windows client, where that uses non-thread-safe stuff.