"Session"lar kaybolmasın!
Bize gelen problemler arasında en çok rastladığımız tanımlardan biri "session'ların kaybolması"dır: "Gün içerisinde kullanıcılar durup dururken şifre giriş sayfasına yönlendiriliyor ve yeniden kullanıcı adı/şifre girmek zorunda kalıyorlar. "
"Session"ın ne olduğundan ve nasıl kullanılması gerektiğinden burada bahsetmeyeceğim. Bu yazının amacı gereği tek söylenmesi gereken şey, "session"ların bir ASP.NET uygulamasında nerede tutulabileceğidir:
- InProc: Bu ön tanımlı değerdir ve bilginin uygulama içerisinde tutulduğu durumdur.
- StateServer: Web uygulamamızın üzerinde çalıştığının dışında, ayrı bir uygulama çalışır ve bilgiler onun üzerinde tutulur.
- SQLServer: Adından da anlaşılacağı üzere, bilgiler SQL Server üzerindeki bir veritabanında tutulur.
Bu üç yöntemin de avantajları ve dezavantajları bulunmaktadır. Bunlar arasında elbette en hızlı olan InProc olacaktır. Çünkü direkt olarak uygulamayla session bilgileri aynı "process" içerisinde yer alır. StateServer, eğer uygulamayla aynı makine üzerinde çalıştırılırsa, neredeyse InProc kadar performanslı olacaktır. Fakat SQLServer'da, veriler ağ üzerinden gidip geleceği için bir miktar performans kaybı olacaktır.
Birden fazla sunucunun bulunduğu ortamlarda (NLB - load balancing) tüm web sunucuları ortak bir "session" tablosu kullanabilmesi, ve dolayısıyla kullanıcıların bir sunucudan diğerine "session"larını kaybetmemesi için en güvenilir yöntem, elbette SQLServer olacaktır.
NEDEN:
Şimdi gelelim asıl konumuz olan "session"ların kaybolmasına... "Session" bilgilerimiz, çok istisnai senaryolar dışında, sadece InProc veya StateServer'da tutuluyorsa kaybolabilir. Çünkü bu iki durumda, "session"lar hafızada (RAM) duruyordur, diskte değil. Dolayısıyla, bir nedenle makine yeniden başlayacak olursa, veya "process" kapanacak olursa, o uygulama üzerindeki "session" biligilerimiz kaybolmuş olacaktır.
"Session" bilgilerini InProc tuttuğumuz durumlarda bir olasılık daha var: Uygulamayı taşıyan IIS "process"i kapanmadan, sadece ASP.NET uygulaması yeniden başlatılabilmektedir. Örneğin, web.config dosyası üzerinde bir değişiklik yapıp kaydettiğinizde, uygulamanın üzerinde çalıştığı "aspnet_wp.exe" veya "w3wp.exe" kapanmadan uygulama yeniden başlayacaktır. Bu durumda da "session"lar kaybolacaktır.
ÇÖZÜM:
"Session"larımız bizim için, daha doğru bir deyişle uygulamamız için, çok önemliyse; veya birden çok sunucumuz varsa; veya IIS "web gardening" özelliğinden yararlanmak istiyorsak, en güvenilir çözüm "session"ı SQL Server'da tutmak olacaktır. Böylece, değil uygulama, sunucunun kendisi bile yeniden başlatılsa "session"larımız kaybolmamış olacaktır.
Eğer bunu yapamıyorsak, veya tercih etmiyorsak, o zaman uygulamamızın yeniden başlatılma zamanlarını düzenlememiz gerekecektir. Bunun için:
- IIS 6.0'daki uygulama havuzlarının (application pool) yeniden başlama ayarlarını düzenleyin. Configure Application Pool Recycling (IIS 6.0)
- Kullanımın yoğun olduğu zamanlarda sunucu üzerindeki web.config dosyasında ve "bin" klasöründe değişiklik yapmayın. Bunlar "process"in değil ama uygulamanın yeniden başlatılmasını tetikleyecektir. Bazı antivirüs veya yedekleme programları da buna neden olabilmektedir. Bu nedenle, belirli bazı klasörlerin bu tür uygulamalar tarafından taranmaması gerekir. Bu linkteki makalemde detaylı bilgi bulabilirsiniz (makale biraz eski olduğundan sadece .NET 1.1'den bahsediyor ama aynı şeyler 2.0 için de geçerlidir).
- Sunucunun olay günlüklerini (event log) izleyin. Herhangi bir nedenle uygulamanızı çalıştıran "process" kapancak olursa, uygulama olay günlüğüne (application event log) mutlaka bir kayıt düşecektir. IIS 6.0 için dikkat etmemiz gereken kayıtların bazıları 1002, 1009, 1010 ve 1011 numaralı kayıtlar olacaktır.
Yukarıda saydığım nedenlerin dışında, "session"ların kaybolmasına neden olabilecek bilinen bir sorun bulunmamaktadır.
CENK ISCAN
Comments
- Anonymous
November 25, 2008
Hocam bu 7.0'da 404 sayfası yönlendirmiyor. web.config'de ayar yaptım. Ama hedef dosyam bir asp dosyası. Acaba iis artık asp desteğini kısıyor mu? - Anonymous
November 27, 2008
ASP desteğiyle ilgili herhangi bir kısıtlama söz konusu değil. IIS 7.0'de de, daha önceki versiyonlar gibi, ASP tam olarak desteklenmektedir. Bahsettiğiniz sorunun nedeni başka birşeydir, ancak ne olduğunu anlamak için yaptığınız ayarları incelemek gerekir. Ayrıca 404 hatasının 15 tane alt kodu bulunmaktadır, bunlardan hangisinde sorun olduğu da önemli olabilir. (http://support.microsoft.com/kb/943891) - Anonymous
September 02, 2010
Merhaba,Bir IIS üzerine aynı projeyi farklı isimlerle kurduğumuzda ve her iki siteye giriş yaptığımızda, ne yazıkki ilk girdiğimiz sitedeki session sonlanıyor. cookieName değiştirmeme rağmen hala problem devam ediyor.Localhost ile girildiğinde session sonlanmıyor fakat networkdeki bir makineden aynı anda bu iki siteyi kullanamıyoruz.(not : iki site tek proje fakat farklı sayfalar kullanılıyor) - Anonymous
September 02, 2010
Projemizin hangi ortamda geliştirildiğini söylememişsiniz. Ancak her tür uygulama (ASP, ASP.NET, hatta PHP) kendi "session"ını kendisi kontrol eder. IIS aslında o işlere pek karısmaz. ASP ve ASP.NET'te bahsettiğiniz gibi bir sorun yaşanmaması lazım. Çünkü default olarak session için kullanılan cookie, siteye girerken kullanılan "hostname" ile eşleştirilir. Dolayısıylaaynı tarayıcıdan bile arka arkaya iki siteye girmemiz, ikisi için ayrı ayrı sesion yaratılmasına neden olacaktır. Bu noktada yaşadığınız sorunun başka bir nedeni olmalı bence. - Anonymous
January 29, 2014
Hocam sessionların karışması gibi bir durumla daha önce karşılaştınız mı?Benim başım şu an o sorunla dertte. Anlayamadığım nokta kullanıcılar işlem yaptıktan sonra üye sayfasına yönlendiriliyor fakat üye sayfasında kullanıcı başka birinin hesabında buluyor kendini kullanıcılar karışıyor. Nette biraz araştırdım sorunun uygulamanın ön bellekte çalışmasından kaynaklandığını yazmışlar. Gerekli düzenlemeleri yaptım fakat hala aynı durumla karşı karşıyayım. Bir de sistem yoğun olduğu zamanlarda bu oluyor. Yardımlarınız için şimdiden teşekkürler.