2009-12-24 2 views
2

Supposons que nous ayons un UserController de bean Spring avec la portée singleton. Tout mon raisonnement supplémentaire est basé sur mon hypothèse que la portée "singleton" est presque similaire à la portée de l'application, c'est-à-dire que nous n'avons qu'une seule instance pour tous les utilisateurs. Si cette supposition est fausse, alors dites-moi s'il vous plaît. Donc, nous avons un formulaire Web avec plusieurs champs. Deux utilisateurs remplissent ce formulaire simultanément. Et ils appuient tous les deux sur le bouton Soumettre en même temps. Notre UserController est un bean backing pour ce formulaire.Sécurité des threads dans JSF

Ma question: est-il possible qu'une partie des champs dans UserController contienne des valeurs du premier utilisateur, et le reste des champs contiendra des valeurs du deuxième utilisateur?

Répondre

2
  1. Vous avez raison singleton = application. Le WebApplicationContext de Spring est stocké dans le ServletContext, donc c'est un par application.

  2. Vos contrôleurs ne doivent pas être de portée singleton. Ils doivent être request ou session. Votre couche de service devrait consister singleton s

  3. Si votre contrôleur est singleton il est assez certain que sera foiré cela tout;)

+0

Merci pour la réponse. Peut-être connaissez-vous aussi certains articles où cette chose décrit? P.S. ce n'est pas "mon contrôleur", je suis en train d'enquêter sur un projet existant. – Roman

+0

Voici un merveilleux how-to pour le printemps + jsf + hibernate http://thelabdude.blogspot.com/2009/04/user-authentication-registration-with.html – Bozho

+0

Bel article avec un certain nombre de choses utiles. – Roman

0

Vous ne devriez pas utiliser un singleton/application scope bean pour gérer les entrées par requête/utilisateur.

Vous voulez probablement un bean tronqué de requête auquel vous pouvez lier les paramètres de formulaire, puis peut-être injecter le bean singleton dans ce bean request si vous avez besoin de quelque chose dans le bean singleton (disons quelque chose comme EntityManager).

4

Dans le paradigme MVC, vous pouvez parfaitement avoir un contrôleur dans le champ d'application (par exemple un Servlet déjà par défaut est), la classe représentative ne devrait pas contenir des champs qui sont associés à la demande des variables scope. Vous devez les déclarer dans le bloc de méthode.

Ainsi par exemple pas

public class Controller { 
    private SomeObject field; // Not threadsafe as this will be shared among all requests! 

    public void control(Request request, Response response) { 
     this.field = request.getSomething(); 
    } 
} 

mais plus

public class Controller { 
    public void control(Request request, Response response) { 
     SomeObject field = request.getSomething(); // Threadsafe. 
    } 
} 

Le View et le Action associé doivent être manipulés ThreadLocal, à savoir déclarée dans le bloc de procédé. Par exemple.

public class Controller { 
    public void control(Request request, Response response) { 
     View view = new View(request, response); 
     Action action = ActionFactory.getAction(request); 
     action.execute(view); 
     view.navigate(); 
    } 
} 

Le Model doit être traité dans la classe Action, également dans le champ d'application ThreadLocal.

public class SomeAction implements Action { 
    public void execute(View view) { 
     Model model = new Model(); 
     // ... 
    } 
} 

Dans le contexte de JSF vous n'ont effectivement la classe Model qui est en rien essence plus qu'un grain de soutien .Les pièces Controller et View sont déjà traitées par JSF avec l'aide de FacesServlet contrôlant les requêtes/réponses/lifecycle/actions et UIViewRoot qui est construit à partir de pages JSF. Ainsi, pour les données de portée de requête, votre bean JSF doit être étendu.

+0

Cela semble raisonnable. Dans le projet décrit, je vois la situation comme dans votre premier bloc de code. – Roman