Wielowątkowy dostęp do zasobów "po polsku" :D

Jak każdy wie, samo programowanie jest wystarczająco trudne, a programowanie wielowątkowe jest trudne do kwadratu. O tym, że jest u nas z tym "krucho" można się było przekonać podczas tegorocznego DevDay 2014 w Krk, podczas którego Dan North wytknął to polskim programistom (głównie tym uczestniczącym na jego warsztatach).

Może ze świadomością wielowątkowości nie jest jakoś super, ale jednak pewna świadomość jest, co pokazała choćby sesja nt. "Modelu aktorów" na Warszawskiej grupie .NET.

A gdzie ja się z tym ost. spotkałem? Ano w aplikacji webowej, którą stworzyłem, a która do generowania raportów wykorzystuje SQL Server Reporting Services w trybie "local reports", tzn. do generowania raportów wykorzystywane są pliki ".rdlc" umieszczone na tym samym serwerze co serwer IIS hostujący stronę web (w moim konkretnym przypadku framework nancyfx).

I o ile przez większość czasu, te raporty generowały się poprawnie, o tyle przed wystawieniem aplikacji dla naszych doradców (pierwsza faza testów objęła ok 50-60 docelowych użytkowników systemu) razem z Adamem K. (osoba z "biznesu") postanowiliśmy przetestować to na x raportów wygenerowanych równocześnie. Zrobiliśmy tak i... klops. Pojawiły się błędy, jedne, te związane z użyciem słówka "static" udało się szybko wyeliminować, to pozostał jeszcze "concurrent access to file".

Stackoverflow.com  zaproponowało synchroniczny dostęp do plików za pomocą "lock". O ile na "początek" to miało sens, tj. wrzucam 'lock'a' "na szybko" i oddaję pierwszą wersję aplikacji użytkownikom do testów, o tyle w docelowej wersji (i kilka razy większej ilości użytkowników) taka wersja systemu była by bardzo niewygodna.

Z pomocą i pomysłem przyszedł mi Michał Kwiatos, który zaproponował rozwiązanie pt. "dla każdego requesta wygeneruj GUID, utwórz katalog z nazwą GUIDa, przekopiuj tam swoje pliki, wykorzystaj je do generowania raportu, a na koniec skasuj niepotrzebny już, śmieciowy katalog", co też zrobiłem i co... rozwiązało mój problem.

I tak sobie teraz myślę, że... najprostsze rozwiązania zwykle bywają najskuteczniejsze.

p.s. mój system docelowo będzie miał mniej niż 500 userów, czyli takie rozwiązanie wydaje się być optymalne. Gdybym tworzył system na +2k userów, to myślę, że na poważnie zastanowił bym się nad implementacją "modelu aktorów" w tym systemie.
p.s.2 wszelkie uwagi mile widziane

MS SQL - DEADLOCK

Czasami zdarzy nam się, że procesy pracujące na bazie danych mogą się zakleszczyć. Nie wdając się w szczegóły, chodzi o równoczesne blokowanie jednych zasobów, oczekując na zwolnienie pozostałych. Szerzej to zagadnienie zostało opisane jako problem ucztujących filozofów.

A co, gdy taka syt. zdarzy nam sie na bazie danych?
a) dobrze by było się dowiedzieć, dlaczego dochodzi do zakleszczeń (np. sql profiler)
b) pomyśleć nad zmianą poziomu izolacji tranzakcji
c) wyśledzić odpowiedni proces za pomocą sp_who2 a nast. ubić zawieszony process, odblokowując tym samym zasoby dla innych procesów

exec sp_who2

kill SPID