Reputation: 2563
Our ticket system vendor provides an .NET API library and I've been trying to make use of this from a multi-threaded application. I'm running into all sorts of connection/stateful issues and I believe this is perhaps because it's not "thread-safe" (I'm still a novice with C# and threaded applications, so just my guess at the moment as some of the symptoms line up).
The API doesn't have a class that is instantiated, you just call the static methods TrebuchetApi.Api.Connect()
and TrebuchetApi.Api.Login()
from it's namespace (in fact all methods appear to be static).
So I maybe have one thread doing one thing, and another doing something else, and the underlying API is getting confused (static variables that should be set are null and such).
Is there any way of making each of my threads use a brand new 'instance' of the API, or is it simply unavoidable?
Update:
For clarity, after the suggestions for using AppDomains I found this article which provided the exact framework I needed: http://www.superstarcoders.com/blogs/posts/executing-code-in-a-separate-application-domain-using-c-sharp.aspx
Upvotes: 1
Views: 458
Reputation: 2865
Using appdomains seems like the way to go.
See How do I prevent static variable sharing in the .NET runtime? or In .Net is the 'Staticness' of a public static variable limited to an AppDomain or the whole process? for similar questions people had.
The msdn guide can be found here http://msdn.microsoft.com/en-us/library/ms173138(v=vs.90).aspx
Just keep in mind that AppDomain is a .net concept, unmanaged resources can still be an issue.
Upvotes: 2