Yes, they are shared throughout the application, independent of threads. For this reason static data are inherently nay thread-safe.
One of the reasons it is often said to avoid its use, or when it does so, to do so safely taking care to synchronize the access.
I think it’s obvious, at least for this aspect, that static objects are not problematic if you don’t have more than one thread in the application.
If the property has not been is not a problem. If the state can never be changed is no problem.
The static property value will always be the last one assigned by any of the threads. At the time of the change all threads see the new value immediately since it is the same place.
Note that in Webapi requests, depending on how it is configured, you may be running different instances of the application. That is, different processes, there is no communication between them.
If you want to create a static class like gambiarra to fix a problem of design current, I would recommend not doing. Static classes are great when they make sense, when they’re really unique things that should be global. One must have a semantics (there are several) to justify its use.
The concrete problem is not yet clear. So it is difficult to say whether this case can be well solved with the use of a static class. But it seems to me thread pool webapi can be a complicator and I wouldn’t use this.
I will give an answer to the 1st. part, the 2nd, would be better to detail more.
– Maniero
Vinicius, I think I could dismember this question in two. Since one is a question of
C#
and the other ofWeb API
.– Randrade
@Bigown updated the question with new details, in case you find a new question as Randrade suggested, I’ll do it. Need some more specific detail?
– Vinícius
@Vinícius may be, but it needs to be more detailed. In general terms, even about the real problem I’m already talking about. But the more specific solution still cannot be answered. If you become more specific, the question may become too broad. So here maybe it’s cool to understand the general and the specific solution can be elsewhere. But I reaffirm, put code, or something that you can better understand what is actually happening.
– Maniero
Your real problem can be better solved if you actually adopt an Onion architecture! The part removed from the question indicates that you have stacked layers, with the business layer knowing the data layer, not a real Onion architecture. In an Onion architecture the persistence context would be configured by the application layer and injected into the business layer with each request, with its scope limited to that request, and you would not need to worry about simultaneous requests (threads). Difficult to detail in a comment and you removed the relevant part of this question.
– Caffé