Co właściwie powoduje wywołanie Session_Start?

Question

W małej aplikacji demo, którą buduję, umieszczam kod inicjujący bazę danych w zdarzeniu Global.Session_Start(). Jednak zauważam, że to zdarzenie nie uruchamia się, gdy korzystam z aplikacji w debugerze na serwerze programistycznym (jeszcze tego nie testowałem nigdzie indziej).

Pytanie 1: Co daje? Kiedy wywoływana jest funkcja Session_Start()? Zakładam, że jest tak, gdy rozpoczyna się sesja, ale czy początek każdej nowej sekwencji żądań nie powinien rozpocząć się automatycznie? Z pewnością sesja powinna się rozpocząć za każdym razem, gdy uruchomię F5, więc dlaczego tak się nie dzieje.

Pytanie 2: Czy istnieje lepsze miejsce, w którym powinien zostać uruchomiony kod inicjujący bazę danych? wolałbym nie umieszczać go w metodzie Application_Start, ponieważ nie zawsze jest wywoływany podczas debugowania.

PS. Przez zainicjowanie bazy danych nie mam na myśli otwarcia połączenia z SqlServer i pozostawienia go na zawsze. Używam db4o i otwieram wstępnie zbudowany plik bazy danych. Jak już mówiłem, to tylko aplikacja demo, nie martwię się złym zarządzaniem zasobami ani nic takiego.

Answer 1

Nie jestem całkowicie pewien, że sesja "rozpoczyna się", dopóki nie uzyskasz dostępu do obiektu Session. W przeciwnym razie wydaje się niepotrzebnym kosztem odpalenia niepotrzebnej sesji.

Answer 2

Z jakiego modelu sesji korzystasz? W przypadku sesji zabezpieczonych programu SQL Server może nie rozpocząć nowych sesji. W przypadku InProc, myślę, że to powinno działać. Aplikacja Application_Start ma problem z czasami wyzwalanymi przed dołączeniem debuggera, jak zauważyłeś.

Czy korzystasz z usług IIS lub serwera sieciowego? W przypadku IIS, this article sugerują, że najpierw trzeba go utworzyć jako aplikację.

Answer 3

Hmm..ok. Może miałoby sens, aby umieścić kod w BeginRequest(), ale jest istnieje sposób, aby umieścić handler na EndRequest(), w którym mogę zamknąć plik bazy danych ?

Kwestia jest taka, że ​​nigdy nie można polegać na tych wydarzeń na ogień, ponieważ runtime ASP.NET decyduje, czy są one opalane czy nie, bo nie może nawet być konieczna i może być pominięta, aby zaoszczędzić zasoby.

Na przykład Response.Redirect anuluje całe przetwarzanie żądania za pomocą wyjątku ThreadAbortException, a zdarzenia cyklu życia strony/kontroli po nim nie zostaną w ogóle uruchomione, dlatego na przykład nie ma End_Request lub czegoś podobnego .

Zastanowiłabym się, czy przenieść logikę do innej warstwy (niezależnie od ASP.NET), i może zainicjować bazę danych, gdy faktycznie jest żądana ze strony? Następnie możesz zamknąć plik bazy danych w taki sam sposób, w jaki potrzebowałeś informacji, co znacznie zwiększyłoby niezależność od stanu aplikacji/sesji.

Nie jesteś pewien, czy to informacja, której szukałeś :)

Answer 4

wiem, że to stary post, ale może to pomoże ktoś:

session_start nie ognia, chyba że faktycznie odczytu lub zapisu do obiektu sesji.

Jeśli chcesz wykorzystać zdarzenie session_start ale nie muszą korzystać z magazynu sesji w ogóle, można dodać następujące dyrektywy page stron docelowych:

<%@ Page EnableSessionState="ReadOnly" %> 

To spowoduje Zdarzenie session_start jest uruchamiane bez konieczności zapisywania czegokolwiek w obiekcie sesji.