Slides a dema z mé přednášky pro konferenci Gopas ShowIT Bratislava z 9.2.2016:
Záznam z přednášky je publikován na našem HAVIT YouTube Channel.
Dotčená témata
V nastavení application poolu na IIS je zastrčeno jedno nastavení s výchozí hodnotou 1, které je poměrně zrádné, pokud ho někdo změní a neví, co to přesně znamená.
Jde o volbu „Maximum Worker Processes“ a neznalé svádí tuto hodnotu z jedničky zvětšit na vyšší číslo.
Co to však ve skutečnosti znamená – jde o to, že IIS pustí pro Application Pool více instancí Worker Processu (w3wp.exe), které jsou navzájem izolované. Vznikne tak více nezávislých instancí aplikací běžících na daném Application Poolu a celé se to začne chovat jako Web Garden (= lokální virtuální Web Farm na jednom serveru). Následky jsou pak prakticky stejné, jako běh aplikace na webové famě – instance aplikace mezi sebou nezdílí kontext (Application, Cache, in-proc Session, atp.).
Protože každý Váš request pak může vyřdit jiná instance aplikace, projevy mohou být např. následující:
Osobně v běžném provozu nenacházím scénář, kde by Maximum Worker Processes mělo být nastaveno jinak než na 1. Dokážu si představit jedině, že někdo chce záměrně testovat chování své aplikace na webové farmě, nebo nějaké obskurní důvody s unmanaged componentami, nebo řešením nedostatečné thread-safety aplikace.
Pokud směřujete ViewState do Session pomocí SessionPageStatePersisteru, pak se dříve nebo později setkáte s problémem ztrát ViewState a s potřebou detekovat a řešit tuto situaci.
Ke ztrátě ViewState může dojít v následujících případech:
Jak takovou situaci detekovat? …overridováním metody LoadPageStateFromPersistenceMedium() v našich stránkách (obvykle pomocí společného předka všech stránek, nějakého PageBase):
protected override object LoadPageStateFromPersistenceMedium()
{
// base implementace vrací new Pair(pageStatePersister.ControlState, pageStatePersister.ViewState);
object pageState = base.LoadPageStateFromPersistenceMedium();
// ztrátu ViewState můžeme tedy detekovat jako (pair.Second == null)
// metoda LoadPageStateFromPersistenceMedium se volá jen pro IsPostBack
Pair pair = pageState as Pair;
if ((pair != null) && (pair.Second == null))
{
Trace.Warn("ViewStateLost !!!");
FormsAuthentication.RedirectToLoginPage();
}
return pageState;
}
Základní (base) implementace metody LoadPageStateFromPersistenceMedium() totiž nedělá celkem nic jiného, než že z použitého persisteru získá ControlState, ViewState a udělá z nich Pair.
Situaci můžeme řešit například tím, že uživatele požádáme o nové přihlášení, či provedeme redirect kamsi do rootu nebo sami na sebe. ViewState už nikde nevydolujeme, musíme z toho nějak vybruslit, aniž bychom uživatele obšťastnili výjimkou NullReferenceException, InvalidFormatException a jinými podobnými, které v takových situacích nastávají.
ViewState se standardně ukládá do formulářového hidden input-fieldu do stránky, posílá se tedy sem a tam na klienta (GET) a zpět na server (POST).
Díky mechanizmu page-adapterů a připraveného SessionPageStatePersister-u lze v ASP.NET velmi snadno přesměrovat ukládání ViewState do Session, tedy na stranu serveru. Primárně je tento mechanizmus určený pro použití se zařízeními (browsery), kde není možné nebo žádoucí view-state pomocí hidden-fieldu přenášet (PDA, mobily, atp.). Nic nám však nebrání rozšířit jeho využití na všechny stránky.
Potřebujeme pouze dvě věci:
Vysvětlovat mechanizmus control-adapterů je mimo rozsah tohoto článku – je to prostě něco, co dokáže poměrně dost modifikovat výchozí chování controlů (a stránka je control), například zajistit jiné renderování, nebo právě způsob ukládání ViewState.
Potřebný page-adapter bude vypadat takto:
public class PageAdapter : System.Web.UI.Adapters.PageAdapter
{
public override PageStatePersister GetStatePersister()
{
return new SessionPageStatePersister(this.Page);
}
}
…nejde o nic jiného, než říci, že se má použít připravený SessionPageStatePersister.
ASP.NET řekneme, že má příslušný page-adapter použít, tak, že modifikujeme/vytvoříme příslušný .browser soubor. Modifikovat lze buď globální nastavení ve složce <windir>\Microsoft.NET\Framework\<ver>\CONFIG\Browsers, nebo pro jednotlivou aplikaci vytvořit .browser soubor do složky ~/App_Browsers.
Soubor ~/App_Browsers/My.browser bude vypadat třeba takto:
<browsers>
<browser refID="Default">
<controlAdapters>
<adapter controlType="System.Web.UI.Page" adapterType="MyNamespace.PageAdapter"/>
</controlAdapters>
</browser>
</browsers>
…to je prakticky vše, co musíme udělat pro ukládání ViewState do Session.
Pokud máme ve svém projektu zavedenu společnou bázovou třídu všech stránek (což každopádně i jinak doporučuji), pal můžeme místo PageAdapteru můžeme i rovnou overridování property PageStatePersister:
protected override PageStatePersister PageStatePersister
{
get
{
if (_pageStatePersister == null)
{
_pageStatePersister = new SessionPageStatePersister(this.Page);
}
return _pageStatePersister;
}
}
private PageStatePersister _pageStatePersister;
…nevýhodou je pevné zakomponování volby Session jako ViewState uložiště do aplikace, na rozdíl od předchozí konfigurační možnosti nad hotovou aplikací.
POZOR!!! Od property PageStatePersister se nedokumentovaně očekává, že ji bude během jednoho requestu možno volat opakovaně a stále bude vracet stejnou instanci! Zatímco metoda PageAdapter.GetStatePersister() je zvnějšku obalena cachováním instance, v property si tento mechanizmus musíme zajistit sami pomocí private fieldu.
SessionPageStatePersister se dá konfigurovat z web.configu pomocí elementu <sessionPageState />:
<system.web> <sessionPageState historySize="9" /> </system.web>
Jediným nastavitelným atributem je historySize, kterým se volí počet ViewState záznamů, které má persister udržovat. Výchozí hodnota je 9.
Východiskem z některých situací je detekce ztráty ViewState.
HAVIT Knowledge Base 