Pourquoi JSF enregistre l'état des composants d'interface utilisateur sur le serveur?
https://stackoverflow.com/questions/5474316
-
14-11-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Jusqu'à quel point dans le temps JSF enregistre l'état des composants de l'interface utilisateur du côté du serveur et quand exactement les informations d'état du composant de l'interface utilisateur sont-elles supprimées de la mémoire du serveur? En tant qu'utilisateur connecté sur l'application navigue à travers les pages, l'état des composants continuera-t-il à s'accumuler sur le serveur?
je ne comprends pas Quel est l'avantage de garder l'état des composants d'interface utilisateur sur le serveur !? Est-ce que passer directement les données validées / converties en haricots gérés n'est-il pas suffisamment? Puis-je ou devrais-je essayer de l'éviter?
Cela ne consomme-t-il pas trop Mémoire côté serveur, s'il y a des milliers de séances utilisateur simultanées? J'ai une application où les utilisateurs peuvent publier des blogs sur certains sujets. Ces blogs sont de taille assez grande. Lorsqu'il y aura de la publication ou de la demande de visualisation des blogs, Ces données de grande page seront-elles enregistrées dans le cadre de l'état des composants? Cela mangerait trop de mémoire. N'est-ce pas une préoccupation?
Mise à jour 1:
Maintenant, il n'est plus nécessaire de sauver l'état lors de l'utilisation de JSF. Une implémentation JSF sans état haute performance est disponible pour une utilisation. Regarde ça Blog & cette question pour les détails et la discussion pertinents. Aussi, il y a un ouvert publier Pour inclure dans les spécifications JSF, une option pour fournir un mode sans état pour JSF. (PS Envisagez de voter pour les problèmes cette & cette Si c'est une fonctionnalité utile pour vous.)
Mise à jour 2 (24-02-2013):
Une belle nouvelle qui Mojarra 2.1.19 est sorti avec mode apatride!
Vois ici:
http://weblogs.java.net/blog/mriem/archive/2013/02/08/jsf-gout-stateless?force=255
La solution
Pourquoi JSF doit-il enregistrer l'état des composants de l'interface utilisateur du côté serveur?
Parce que HTTP est apatride et JSF est avec état. L'arbre de composant JSF est soumis à des changements dynamiques (programmatiques). JSF a simplement besoin de connaître l'état exact tel qu'il était lorsque le formulaire avait été affiché à l'EndUser, afin qu'il puisse traiter avec succès l'intégralité du cycle de vie JSF en fonction des informations fournies par l'arborescence des composants JSF d'origine lorsque le formulaire a été soumis à le serveur. L'arborescence des composants fournit des informations sur les noms de paramètres de demande, les convertisseurs / validateurs nécessaires, les propriétés et méthodes d'action du bean gérées liées.
Jusqu'à quel point dans le temps JSF enregistre l'état des composants de l'interface utilisateur du côté serveur et quand exactement les informations d'état du composant de l'interface utilisateur sont-elles supprimées de la mémoire du serveur?
Ces deux questions semblent se résumer à la même chose. Quoi qu'il en soit, cela est spécifique à l'implémentation et dépend également de l'enregistrement de l'état sur le serveur ou le client. Une implémentation un peu décente le supprimera lorsqu'il a été expiré ou lorsque la file d'attente est pleine. Mojarra, par exemple, a une limite par défaut de 15 vues logiques lorsque l'enregistrement de l'état est défini sur la session. Ceci est configurable avec le contexte de contexte suivant dans web.xml:
<context-param>
<param-name>com.sun.faces.numberOfLogicalViews</param-name>
<param-value>15</param-value>
</context-param>
Voir également FAQ de Mojarra pour d'autres paramètres spécifiques à Mojarra et cette réponse connexe com.sun.faces.numberofViewSinsession vs com.sun.faces.numbumberoflogicalViews
En tant qu'utilisateur connecté sur l'application navigue à travers les pages, l'état des composants continuera-t-il à s'accumuler sur le serveur?
Techniquement, cela dépend de la mise en œuvre. Si vous parlez de navigation de page à page (obtenez simplement des demandes), Mojarra ne sauvera rien en session. S'ils sont cependant des demandes de poste (formulaires avec des liens de commande / boutons), Mojarra enregistrera l'état de chaque formulaire de session jusqu'à la limite maximale. Cela permet à l'EndUser d'ouvrir plusieurs formulaires dans différents onglets de navigateur dans la même session.
Ou, lorsque la sauvegarde de l'état est définie sur le client, JSF ne stockera rien en session. Vous pouvez le faire par le contexte de contexte suivant dans web.xml:
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
Il sera ensuite sérialisé en une chaîne cryptée dans un champ de saisie caché avec le nom javax.faces.ViewState de la forme.
Je ne comprends pas quel est l'avantage de garder l'état du composant d'interface utilisateur côté serveur. Est-ce que passer directement les données validées / converties en haricots gérés n'est-il pas suffisamment? Puis-je / devrais-je essayer de l'éviter?
Cela ne suffit pas pour assurer l'intégrité et la robustesse de JSF. JSF est un cadre dynamique avec un seul point de contrôle d'entrée. Sans gestion de l'État, on pourrait parvenir à des demandes HTTP par une certaine manière (par exemple, manipuler disabled, readonly et rendered Attributs), pour laisser JSF faire des choses différentes et potentiellement dangereuses. Il serait même sujet aux attaques du CSRF et au phishing.
Et cela ne consomme-t-il pas trop de mémoire côté serveur, s'il y a des milliers de séances utilisateur simultanées? J'ai une application où les utilisateurs peuvent publier des blogs sur certains sujets. Ces blogs sont de taille assez grande. Lorsqu'il y aura de la publication ou de la demande de visualisation des blogs, les grands blogs seront enregistrés dans le cadre de l'état des composants. Cela consommerait trop de mémoire. N'est-ce pas une préoccupation?
La mémoire est particulièrement bon marché. Donnez simplement à appserver suffisamment de mémoire. Ou si la bande passante du réseau est moins chère pour vous, changez simplement d'enregistrement de l'état vers le côté client. Pour trouver la meilleure correspondance, stressez-vous et profitez de votre webapp avec une quantité maximale d'utilisateurs simultanés attendue, puis donnez à l'appservateur 125% ~ 150% de la mémoire mesurée maximale.
Notez que JSF 2.0 a beaucoup amélioré la gestion de l'État. Il est possible d'économiser un état partiel (par exemple seulement la <h:form> sera sauvé au lieu de tout ce <html> jusqu'à la fin). Mojarra par exemple le fait. Un formulaire moyen avec 10 champs d'entrée (chacun avec une étiquette et un message) et 2 boutons ne prendraient pas plus de 1 Ko. Avec 15 vues en session, cela ne devrait pas dépasser 15 Ko par session. Avec ~ 1000 sessions utilisateur simultanées, cela ne devrait pas dépasser 15 Mo.
Votre préoccupation doit être davantage axée sur les objets réels (haricots gérés et / ou même entités DB) dans la séance ou la portée de l'application. J'ai vu beaucoup de codes et de projets qui reproduisent inutilement l'intégralité du tableau de la base de données dans la mémoire de Java dans la saveur d'un haricot étendu de session où Java est utilisé à la place de SQL pour filtrer / groupe / organiser les enregistrements. Avec ~ 1000 enregistrements, cela dépasserait facilement 10 Mo par session utilisateur.
