Pourquoi JSF sauvegarde L'état des composants UI sur le serveur?

  1. Jusqu'à quel moment JSF enregistre-t-elle L'état des composants UI du côté du serveur et quand exactement les informations de l'état du composant UI sont-elles retirées de la mémoire du serveur? Comme un utilisateur connecté sur l'application accède bien des pages, l'état des composants continuent à accumuler sur le serveur?

  2. je ne comprends pas quel est l'avantage de garder les composants de l'INTERFACE utilisateur de l'état sur le serveur !? ne suffit-il pas de transmettre directement les données validées/converties à managed beans? Puis-je ou devrais-je essayer de l'éviter?

  3. ne consomme-t-il pas trop de mémoire du côté du serveur, s'il y a des milliers de sessions utilisateurs simultanées? J'ai une application où les utilisateurs peuvent publier des blogs sur certains sujets. Ces blogs sont assez grands en taille. Quand il y aura post back ou demande pour voir le les blogs, les cette grande page de données seront enregistrées dans le cadre de l'état des composants? cela détruirait trop de mémoire. N'est-ce pas un sujet de préoccupation ?


Maj 1:

maintenant, il n'est plus nécessaire de sauvegarder l'état en utilisant JSF. Une mise en œuvre de JSF à haut rendement et sans état est disponible pour utilisation. Voir cette blog & cette question pour les détails pertinents et de discussion. En outre, il y a une "question" ouverte 1519310920 à inclure dans les spécifications JSF, une option pour fournir le mode apatride pour JSF. (P. S. Envisager de voter pour les questions ce & ce si cette fonctionnalité est utile pour vous.)



Maj 2 (24-02-2013):

une grande nouvelle que Mojarra 2.1.19 est avec apatrides mode !

voir ici:

http://weblogs.java.net/blog/mriem/archive/2013/02/08/jsf-going-stateless?force=255

http://java.net/jira/browse/JAVASERVERFACES-2731

http://balusc.blogspot.de/2013/02/stateless-jsf.html

97
demandé sur Community 2011-03-29 18:39:21
la source

1 ответов

pourquoi JSF doit-elle sauvegarder l'état des composants UI du côté du serveur ?

parce que HTTP est apatride et JSF est stateful. L'arborescence des composantes du JSF est sujette à des changements dynamiques (programmatiques). JSF a simplement besoin de connaître l'état exact tel qu'il était lorsque le formulaire a été affiché à l'utilisateur final, afin de pouvoir traiter avec succès l'ensemble du cycle de vie JSF sur la base des informations fournies par le l'arborescence originale des composants JSF lorsque le formulaire a été renvoyé au serveur. L'arborescence des composants fournit des informations sur les noms des paramètres de requête, les convertisseurs/validateurs nécessaires, les propriétés des fèves gérées liées et les méthodes d'action.


Jusqu'à quel moment JSF sauve l'état des composants D'UI du côté du serveur et quand exactement les informations D'état du composant D'UI sont retirées de la de mémoire de serveur?

ces deux questions semblent se résumer à la même chose. Quoi qu'il en soit, ceci est spécifique à l'implémentation et dépend également du fait que l'État soit sauvegardé sur le serveur ou sur le client. Un peu d'implémentation décente va le supprimer quand il a expiré ou quand la file d'attente est pleine. Mojarra, par exemple, a une limite par défaut de 15 Vues logiques lorsque l'état de sauvegarde est défini à session. Ceci est configurable avec le contexte suivant param en web.xml :

<context-param>
    <param-name>com.sun.faces.numberOfLogicalViews</param-name>
    <param-value>15</param-value>
</context-param>

Voir aussi Mojarra FAQ pour d'autres Mojarra spécifiques params et cette réponse com.soleil.face.numberOfViewsInSession vs com.soleil.face.numberOfLogicalViews


Comme un utilisateur connecté sur l'application accède bien des pages, l'état des composants continuent à accumuler sur le serveur?

Techniquement, cela dépend de la mise en œuvre. Si vous parlez de navigation de page en page (il suffit d'obtenir des requêtes), alors Mojarra ne sauvera rien en session. S'il s'agit de requêtes POST (formulaires avec liens command/boutons), alors Mojarra enregistrera l'état de chaque formulaire en session jusqu'à la limite max. Cela permet à l'utilisateur final d'ouvrir plusieurs formulaires dans différents onglets de navigateur dans la même session.

ou, lorsque l'économie d'état est réglée à client, alors JSF ne stockera rien en session. Vous pouvez le faire par le contexte suivant param web.xml :

<context-param>
    <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
    <param-value>client</param-value>
</context-param>

il sera alors sérialisé en chaîne cryptée dans un champ caché d'entrée avec le nom javax.faces.ViewState du formulaire.


Je ne comprends pas quel est l'avantage de maintenir L'état du composant de L'interface utilisateur du côté du serveur. N'est pas directement en passant le les données validées/converties en haricots gérés sont-elles suffisantes? Peux/dois-je essayer de l'éviter?

ce n'est pas suffisant pour assurer l'intégrité et la robustesse du JSF. Le JSF est un cadre dynamique doté d'un point de contrôle unique. Sans gestion d'état, on serait capable de mystifier/pirater les requêtes HTTP d'une certaine manière (par exemple en manipulant les attributs disabled , readonly et rendered ), pour laisser JSF faire des choses différentes-et potentiellement dangereuses. Il serait même sujet à des attaques CSRF et hameçonnage.


et ne consommera-t-il pas trop de mémoire du côté du serveur, s'il y a des milliers de sessions utilisateurs simultanées? J'ai une application où les utilisateurs peuvent publier des blogs sur certains sujets. Ces blogs sont assez grands en taille. Quand il y aura un post back ou une demande pour voir les blogs, les grands blogs seront sauvegardés dans le cadre de l'état des composants. Ce serait consommer trop de mémoire. N'est-ce pas un sujet de préoccupation?

la Mémoire est particulièrement bon marché. Donnez juste assez de mémoire à l'applicateur. Ou si la bande passante réseau est moins chère pour vous, passez simplement à l'économie d'État côté client. Pour trouver le meilleur match, juste stresstest et profiler votre webapp avec le nombre maximum prévu d'utilisateurs concurrents et ensuite donner à l'applserver 125% ~ 150% de la mémoire maximale mesurée.

notez que JSF 2.0 a amélioré beaucoup dans la gestion de l'état. Il est possible de sauvegarder l'état partiel (par exemple seulement le <h:form> sera sauvegardé à la place de la substance entière de <html> jusqu'à la fin). Mojarra par exemple le fait que. Une forme moyenne avec 10 champs d'entrée (chacun avec une étiquette et un message) et 2 boutons ne prendrait pas plus de 1KB. Avec 15 vues en session, cela ne devrait pas être plus de 15KB par session. Avec ~1000 sessions utilisateurs simultanées, cela ne devrait pas dépasser 15 Mo.

votre préoccupation devrait être plus axée sur les objets réels (haricots gérés et/ou même entités DB) dans le cadre de la session ou de l'application. J'ai vu beaucoup de codes et de projets qui dupliquent inutilement l'ensemble de la table de base de données dans la mémoire de Java dans la saveur d'une session scoped bean où Java est utilisé au lieu de SQL pour filtrer/group/arranger les enregistrements. Avec ~1000 enregistrements, cela dépasserait facilement 10MB par session utilisateur .

191
répondu BalusC 2017-05-23 14:47:05
la source

Autres questions sur java jsf java-ee state-saving