JSF'nin neden UI bileşenlerinin durumunu sunucu tarafında kaydetmesi gerekiyor?
Çünkü HTTP durum bilgisizdir ve JSF durum bilgilidir. JSF bileşen ağacı, dinamik (programlı) değişikliklere tabidir. JSF, formun son kullanıcıya görüntülendiği andaki tam durumu tam olarak bilmesi gerekir, böylece form geri gönderildiğinde orijinal JSF bileşen ağacının sağladığı bilgilere dayanarak tüm JSF yaşam döngüsünü başarıyla işleyebilir. sunucu. Bileşen ağacı, istek parametresi adları, gerekli dönüştürücüler / doğrulayıcılar, bağlı yönetilen fasulye özellikleri ve eylem yöntemleri hakkında bilgi sağlar.
JSF hangi noktaya kadar UI bileşenlerinin durumunu sunucu tarafında kaydeder ve UI bileşeninin durum bilgisi sunucu belleğinden tam olarak ne zaman kaldırılır?
Bu iki soru aynı şekilde özetleniyor. Her neyse, bu uygulamaya özgüdür ve ayrıca durumun sunucuya mı yoksa istemciye mi kaydedildiğine bağlıdır. Biraz düzgün bir uygulama, süresi dolduğunda veya kuyruk dolduğunda onu kaldıracaktır. Örneğin Mojarra, durum kaydetme oturuma ayarlandığında varsayılan 15 mantıksal görünüm sınırına sahiptir. Bu, aşağıdaki bağlam parametresi ile yapılandırılabilir web.xml:
<context-param>
<param-name>com.sun.faces.numberOfLogicalViews</param-name>
<param-value>15</param-value>
</context-param>
Ayrıca Mojarra'ya özgü diğer parametreler için Mojarra SSS bölümüne ve bu ilgili yanıt com.sun.faces.numberOfViewsInSession ile com.sun.faces.numberOfLogicalViews'a bakın
Uygulamada oturum açmış bir kullanıcı sayfalarda gezinirken, bileşenlerin durumu sunucuda birikmeye devam edecek mi?
Teknik olarak, bu uygulamaya bağlıdır. Sayfadan sayfaya gezinmeden bahsediyorsanız (sadece GET istekleri), Mojarra oturumda hiçbir şey kaydetmez. Ancak bunlar POST istekleriyse (komut bağlantılı / düğmeli formlar), Mojarra oturumdaki her formun durumunu maksimum sınıra kadar kaydedecektir. Bu, son kullanıcının aynı oturumda farklı tarayıcı sekmelerinde birden çok form açmasını sağlar.
Veya durum kaydetme istemciye ayarlandığında, JSF oturumda hiçbir şey saklamaz. Bunu, aşağıdaki bağlam parametresiyle yapabilirsiniz web.xml:
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
Daha sonra javax.faces.ViewState, formun adıyla gizli bir giriş alanında şifrelenmiş bir dizeye serileştirilecektir .
UI bileşeninin durumunu sunucu tarafında tutmanın faydasının ne olduğunu anlamıyorum. Doğrulanmış / dönüştürülmüş verileri doğrudan yönetilen Bean'lere geçirmek yeterli değil mi? Bundan kaçınmaya çalışabilir miyim / denemeli miyim?
JSF'nin bütünlüğünü ve sağlamlığını sağlamak için bu yeterli değildir. JSF, tek bir giriş kontrol noktasına sahip dinamik bir çerçevedir. Durum yönetimi olmadan , JSF'nin farklı ve potansiyel olarak tehlikeli şeyler yapmasına izin vermek için disabled, HTTP isteklerini belirli bir şekilde (örn. Manipüle etme readonlyve renderedöznitelikler) sahtekarlık / hackleme yapılabilir. CSRF saldırılarına ve kimlik avına bile eğilimli olacaktır.
Binlerce eşzamanlı kullanıcı oturumu varsa, bu sunucu tarafında çok fazla bellek tüketmez mi? Kullanıcıların belirli konularda blog yayınlayabilecekleri bir uygulamam var. Bu bloglar oldukça büyük boyuttadır. Blogları görüntüleme talebi veya geri gönderi olduğunda, büyük bloglar bileşenlerin durumunun bir parçası olarak kaydedilecektir. Bu çok fazla hafıza tüketir. Bu bir endişe değil mi?
Hafıza özellikle ucuzdur. Uygulama sunucusuna yeterli bellek verin. Veya ağ bant genişliği sizin için daha ucuzsa, durum tasarrufunu istemci tarafına geçirmeniz yeterlidir. En iyi eşleşmeyi bulmak için sadece stres atın ve web uygulamanızı beklenen maksimum eşzamanlı kullanıcı sayısı ile profilleyin ve ardından uygulama sunucusuna ölçülen maksimum belleğin% 125 ~% 150'sini verin.
JSF 2.0'ın durum yönetiminde çok geliştiğini unutmayın. Kısmi durumu kaydetmek mümkündür (örneğin , baştan sona tüm şeyler yerine sadece<h:form> kaydedilecektir <html>). Örneğin Mojarra bunu yapar. 10 giriş alanı (her biri bir etiket ve mesaj içeren) ve 2 düğme içeren ortalama bir form 1 KB'tan fazla yer almaz. Oturumda 15 görünüm ile bu, oturum başına 15 KB'tan fazla olmamalıdır. ~ 1000 eşzamanlı kullanıcı oturumuyla, bu 15MB’den fazla olmamalıdır.
Endişeniz, oturum veya uygulama kapsamındaki gerçek nesnelere (yönetilen fasulye ve / veya hatta DB varlıkları) daha fazla odaklanmalıdır. Kayıtları filtrelemek / gruplamak / düzenlemek için SQL yerine Java'nın kullanıldığı oturum kapsamlı bir fasulye çeşidinde, tüm veritabanı tablosunu Java'nın belleğine gereksiz yere kopyalayan birçok kod ve proje gördüm. ~ 1000 kayıtla, bu, kullanıcı oturumu başına kolayca 10MB'nin üzerine çıkar .