Bonjour,
Je voudrais savoir s'il est possible de déclarer un constructeur avec des paramètres sur un EJB session stateful, et comment l'appeler (lors du lookup ???)
Merci d'avance pour vos réponses (et votre indulgence)
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Constructeur avec paramètres ?
Bonjour,
Je voudrais savoir s'il est possible de déclarer un constructeur avec des paramètres sur un EJB session stateful, et comment l'appeler (lors du lookup ???)
Merci d'avance pour vos réponses (et votre indulgence
De même, est-il possible - et opportun - de stocker une connexion JDBC sur un EJB Session Stateful ?
la méthode create du Home de ton ejb invoque la méthode ejbCreate de l'implem de ton ejb. Ca initialise donc ton ejb.
La méthode ejbCreate se surcharge à ta guise.
Il ne faut surtout pas stocker une connexion JDBC sur un EJB Session Stateful.
Si la méthode métier de ton ejb a besoin de se connecter à la base de données, elle récupère le datasource via jndi par exemple ou en tant que resource.
Mes 2 réponses valent pour les ejb 2.1 et avant
Et pour les EJB3? la réponse m'intéresse aussi pour stocker une connexion CORBA.Envoyé par phantomass
Les composants SWING |
Pensez au bouton
une fois le problème résolu
Merci pour ta réponse.
+1, je bosse en EJB3 également... La surcharge de l'ejbCreate est-elle toujours possible ?
Il semblerait q'uen EJB 3, il est possible d'utiliser ejbCreate si on utilise un Home. Mais l'usage d'un home est facultatif et même démodé.
Il est possible d'annoter des méthodes avec @Init ou @postContruct qui seront de toute façon invoquées avant le 1er appel d'une méthode métier de l'EJB.
Par contre je ne sais pas comment utiliser des arguments sur ces méthodes. :-(
Pour ta question de passer un paramtre à un EJB Session pourquoi ne recuperes tu pas simplement une instance via JNDI sur laquelle tu feras un setter simplement?
Vous avez peut être hâte de réussir et il n'y a rien de mal à cela...
mais la patience est aussi une vertu; l'échec vous l'enseignera certainement..."
Parce ce n'était pas ma question, et que ça m'étonne de ne pas pouvoir le faire...
Mais c'est vrai que c'est ce à quoi j'ai également pensé, d'où ma 2ème question : est-il possible de passer une connexion JDBC à un EJB afin qu'il la stocke tout au long de son cycle de vie ?
Euh, a priori, il n'est pas conseillé de passer un connexion JDBC a un EJB.
Surtout si ton EJB est remote, ca n'a pas vraiment de sens car je doute que la connexion JDBC soit serializable.
Par contre, avoir un EJB stateful qui obtient une connection de lui meme et qui la garde devrait etre possible. Par contre, je ne sais pas trop ce que ca donne niveau performance, car ta connection ne sera pas remise dans le pool, et au bout d'un certain nombre de bean, ton pool sera vide...
A mon avis, il vaut mieux redemander une connection a chaque fois, et ce faisant, s'appuyer sur la gestion de pool du serveur d'application. Car que tu fais un close sur une connection venant da l'AS, elle n'est pas vraiment fermée, mais simplement remise dans le pool de connections disponibles.
En tout cas, c'est comme ca que ca marche dans JOnAS
Merci pour ta réponse.
En effet la connexion JDBC ne doit pas pouvoir être sérialisée, car je me chope une exception à un moment donné (à la passivation de l'EJB j'imagine).
Je sais qu'en stockant la connexion sur l'EJB, je me prive des avantages du pool de connexion fourni par le serveur d'applications, mais il me faut garder des résultsets ouverts un certain temps.
I'm stucked...
Ca veut dire quoi concretement dans ton cas ?
Tu n'es jamais sensé garder des ResultSet ouvert "un certain temps" .
Bah oui mais là si. Coté client j'ai une page qui contient une 50aine d'enregs issus du resultset, et l'utilisateur peut faire "page suivante" ou "page précédente". D'où le besoin de garder le RS ouvert pour pouvoir faire les 50 .next ou .prev nécessaires.
EDIT : mais ce n'est toujours pas ma question
Justement c'est une très mauvaise stratégie d'implementation.
En général tu te demerdes pour garder les informations relatives à ta pagination, mais à chaque appel client tu dois refaire la requete en base et afficher les lignes qui concerne ta page.
Ca peut paraitre couteux, mais ça l'est beaucoup de monopoliser une connexion le temps qu'un client lise les infos de la page.
DésoléEDIT : mais ce n'est toujours pas ma question
C'est plus couteux de garder une connexion ouverte que de refaire une requête qui ramène 200.000 enregistrements et faire un absolute() pour retrouver la ligne où tu étais ?
La formulation était rustre et je m'en excuse.
Mais c'est vrai que je ne sais tjs pas comment faire - même si j'ai bien compris que c'est pas terrible...
Peut etre peux tu avoir une requete SQL qui supporterait l'option LIMIT, comme ca tu peux faire directe la requete SQL qui te retournera seulment les n premiers resultats...
Je ne suis pas sur que LIMIT soit un standard SQL. D'ailleurs je crois que ce n'est pas implémenté sous Oracle. Il faut alors manier le ROWNUM, et les temps de réponses sont vraiment pas terribles.
C'est plutôt setMaxRows(int) qu'il faudrait utiliser sur le statement avant d'exécuter la requête...
Pour ce qui est des 200.000 lignes, dans tous les cas, je ne pense pas qu'un utilisateur s'amusera à lire tous tes blocs de 50 enregistrements jusqu'à la fin (ou alors, il n'a vraiment que ça à faire), il serait opportun de favoriser les critères de filtre pour limiter le nombre d'enregistrements.
Si je peux me permettre (et je sais que ce n'est pas ta question), c'est plutôt aberrant de garder une connexion ouverte pendant plusieurs minutes (et encore plus si c'est dans un contexte web/html)
A ce sujet, quel est le type du client ?
Si je me souviens bien, la méthode setMaxRows est dispo sur le resultset, (équivalent de l'hint Oracle first_rows, peut-etre) afin de fetcher +/- d'enregs ? Cependant j'imagine que la requête est bel & bien exécutée en totalité par le SGBD.
C'est plus que vrai, encore plus dans un état d'esprit orienté Web. Malheureusement, le prérequis est "on ne touche pas à la logique algorithmique"... Donc quand l'utilisateur ouvre la liste des articles, bah il lui faut les 200.000 articles, même s'il va surement les filtrer par la suite. Damned !Pour ce qui est des 200.000 lignes, dans tous les cas, je ne pense pas qu'un utilisateur s'amusera à lire tous tes blocs de 50 enregistrements jusqu'à la fin (ou alors, il n'a vraiment que ça à faire
C'est clair. En fait le but du jeu est de faire un truc totalement contre nature : passer une appli client / serveur pas Java en Java, en commençant par la partie serveur et en ne touchant pas au client. Et si possible, faire le minimum syndical pour l'intégrer dans JBoss (d'où mon idée de créer 1 EJB session stateful par client et d'y stocker la connexion).
Ca occupe !
Et bien, à priori, dans ton cas...
Si je me souviens bien, dans la plupart des applications client/serveur, les clients ouvrent une connexion au démarrage de l'application et la ferme quand ils quittent.
Donc, si tu as autant de connexions disponibles que de clients, pourquoi pas... il serait peut-être intéressant de mettre un timeout (au cas où)
Par contre, sans modifier les clients, comment vas-tu faire pour accéder à l'EJB ?
On a mis en place un frontal côté client qui modifie le flux initialement envoyé au serveur selon un protocole défini, et un "dispatcher" côté serveur qui analyse le flux et fait ce qu'il faut. C'est déjà fonctionnel avec des classes Java "standards", entre autre une classe Contexte qui possède la connexion à la BDD.
D'où mon idée de passer cette dite classe au format EJB...
D'où ma question de stockage d'une connexion JDBC sur un EJB...
D'où ma remise en cause quant à ma vocation à faire du développement
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager