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 :roll:)
Version imprimable
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 :roll:)
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.Citation:
Envoyé par phantomass
Merci pour ta réponse.
+1, je bosse en EJB3 également... La surcharge de l'ejbCreate est-elle toujours possible ?Citation:
Envoyé par morph41
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?
Parce ce n'était pas ma question, et que ça m'étonne de ne pas pouvoir le faire...Citation:
Envoyé par DevServlet
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 ?Citation:
Envoyé par DevTeam_
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.Citation:
Envoyé par phantomass
EDIT : mais ce n'est toujours pas ma question
Justement c'est une très mauvaise stratégie d'implementation.Citation:
Envoyé par DevTeam_
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éCitation:
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.:?Citation:
Envoyé par phantomass
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.Citation:
Envoyé par kalysto
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 :mouarf:), 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.Citation:
Envoyé par OButterlin
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 !Citation:
Envoyé par OButterlin
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).Citation:
Envoyé par OButterlin
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.Citation:
Envoyé par OButterlin
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 :aie:
Pourquoi pas, ce n'est pas parce que ce n'est pas "standard" qu'il ne faut pas le faire dans certains cas. En plus, ça sent le "temporaire"...Citation:
Envoyé par DevTeam_
Mais non, faut pas être négatif :mrgreen:Citation:
Envoyé par DevTeam_
A la base, tu voulais utiliser des arguments pour la création de l'EJB3, là, je ne vois pas trop... je ne sais même pas si c'est possible...
Les paramètres représentaient quoi ? Les paramètres de la connexion ?
Personnellement pour résoudre mon problème équivalent (pour une connexion corba) je vais utiliser un setter, et si on appelle la méthode métier sans avoir initialisé l'EJB via le setParametre, je renverrai une exception (genre IllegalStateException : EJB not initialized).
C'est le seul moyen que j'ai trouvé :?
L'enfer est pavé de bonnes intentions, et les mauvaises applis de trucs temporaires vieux de 10 ans...Citation:
Envoyé par OButterlin
Je ne suis pas du tout gêné par le concept de "non EJB-proof", la seule limite c'est l'exception levée quand je tente de stocker la connexion sur l'EJB. On en revient à notre feeling de non-serializable...
La connexion JDBC, justement !Citation:
Envoyé par OButterlin
C'est pas bête, mais ça veut dire qu'on a régressé lors du passage EJB2.1=>3 ? Ah moins qu'il n'y ait une bonne raison au fait de ne plus pouvoir passer de paramètres...Citation:
Envoyé par morph41
Bon, pour la connexion, il y a peut-être moyen de contourner le problème.
Si tu positionne l'objet Connection comme ceci System.getProperties().setProperty("Connexion1", connection), tu pourras la récupérer par System.getProperties().getProperty("Connexion1");
(Là, on est au niveau jvm il me semble)
Du coup, tu n'as plus besoin du paramètre...
(ça reste de la bidouille :aie:)