G encors du mal avec les interfaces.
En fait là, c un pb de conception que j'ai. J'explique:
Je crée un logiciel en Java qui bosse avec une base de données.
Cet outil crée une quizaine de tables, qu'il utilisera pour faire ce qu'il a a faire. La structure des tables qu'il cré est toujours la même.
Je voudrais donc créer une classe Java par table existante.  
Je prend un exemple, sinon j'arriverai jammais à expliquer.
J'ai une table USER, qui comporte les champs varchar Login et varchar Password.
Cette classe aurait les attributs privés String m_Login et String m_Passord. Elle permettrai de faire une requete sur cette table, et elle permettrai de récupérer un à un chacun des résultat rendu. J'en déduis donc que cette classe devra implémenter Statement et ResultSet, non !?
Et si cette claasse implémente ces 2 interfaces, je suis obligé de définir chacune des méthodes de ces interfaces. C impossible !
Comment je fais !? à l'aide, j'me perd !

[jfdsdjhfuetppo]--Message édité par el_gringo le 29-05-2002 à 15:58:09--[/jfdsdjhfuetppo]

nooon, elle est pas obligée d'implémenter Statement et ResultSet : elle peut UTILISER Statement et ResultSet : les implémentations de statement et resultset sont faites dans le driver JDBC..

pourquoi aurait tu besoin d'hériter de Statement ou ResultSet ?

bha oui. C'est des classes qui tu utilises ... t'es pas à les redéfinir ...

Ouais, dsl pour cette question nulle !    
Ce truc, c'est dans une servlet que je veux le faire.
Je dois avoir une instance de Connection par Session (par poste client quoi), ou une seule pour tout le monde et une instance de Statement par Session !?
 
Là, je dis pas une connerie si je fais ça:
Je crée une classe UserConnected qui hérite de HttpSession.
comme membre de UserConnected, je dois avoir une instance de Connection ou une instance de Statement ?

[jfdsdjhfuetppo]--Message édité par el_gringo le 29-05-2002 à 17:30:10--[/jfdsdjhfuetppo]

hé !? y a pu personne !?

Mais...Pourquoi tu veux absolument hériter de Connection????
 
Dans la méthode de ton User qui va aller remplir les attributs à partir de la base, tu t'arranges pour récupérer une connection, genre :  
 
java.sql.DriverManager.getConnection(url)..
 
Et ensuite, tu utilises ta connection, et tu la fermes à la fin, et ouala!

 
g jammais dis que je voulais hériter de Connection !!!!
Je demandais ,sachant que mon truc est utilisé ds une servlet, s'il faut que je crée une nouvelle connection (par un DriverManager.getConnection, oui) à chaque fois qu'un utilisateur se connecte (qu'un nouvelle Session est crée), ou bien est ce que je doit avoir une seule connection pour ma servlet que les utilisateurs partageront...

Ahhh, okaye..scuse....
 
'tain, vaste problème....Ici, on a un mec qui s'est tapé la programmation d'un ConnectionManager, qui gère un pool de connections, et qui qui fait tout le boulot d'en ouvrir en plus quand il en a pas assez, etc, etc.....là, je sais pas trop...je suis pas spécialiste de la question, franchement..

Par contre, ça parait logique que UserConnected hérite de HttpSession, puisque c'est une session Http...
Non !?

[jfdsdjhfuetppo]--Message édité par el_gringo le 29-05-2002 à 17:46:00--[/jfdsdjhfuetppo]

 
Et c'est qui ce mec !? Si y me le prête, je le veut bien moi sont ConnectionManager !

el_gringo a écrit a écrit :     Et c'est qui ce mec !? Si y me le prête, je le veut bien moi sont ConnectionManager !

 
Haha, tu doutes de rien!! D naan, malheureusement, c du code propriétaire..
Sinon, non, User ne doit pas à mon avis, hériter de HttpSession. Ca doit être une valeur au sein de la session...A la limite, implémenter HttpSessionBindingListener, histoire d'être mis au courant au moment où la session se termine (en gros, si un objet implémente cette interfacen, et que tu le met dans la session, à la cloture de la session, la méthode valueUnbound(HttpSessionBindingEvent event) est appellée, et valueBound(HttpSessionBindingEvent event) est appellée au démarrage de la session)

gfive a écrit a écrit :     Haha, tu doutes de rien!! D naan, malheureusement, c du code propriétaire.. Sinon, non, User ne doit pas à mon avis, hériter de HttpSession. Ca doit être une valeur au sein de la session...A la limite, implémenter HttpSessionBindingListener, histoire d'être mis au courant au moment où la session se termine (en gros, si un objet implémente cette interfacen, et que tu le met dans la session, à la cloture de la session, la méthode valueUnbound(HttpSessionBindingEvent event) est appellée, et valueBound(HttpSessionBindingEvent event) est appellée au démarrage de la session)

 
Maieuuu, ça serait juste pour me le prêter, après je lui rend son code !
Plus sérieusement, avce ce que tu dis + réflexion de ma part, c vrai que je vais pas hériter mon UserConnected de HttpSession.
Merci.

C'est quoi ta classe UserConnected ? pkoi elle hériterait de HttpSession ?
 
si comme je le crois, c'est un objet qui va stocker les données concernant un utilisateur dont tu vas avoir besoin dans tes servlets, la répnse est non.
Tu va utilisé les session, mais pourquoi veux tu en hériter ?

el_gringo a écrit a écrit :     Maieuuu, ça serait juste pour me le prêter, après je lui rend son code ! Plus sérieusement, avce ce que tu dis + réflexion de ma part, c vrai que je vais pas hériter mon UserConnected de HttpSession. Merci.

 
Je pense (mais je peux me tromper...) que tu t'embrouille un peu...
 
tu devrais te poser les questions suivantes (i.e. faire un peu de conception):
 
1) ai je plusieurs utilisateurs simultanés?
2) ai je besoin d'une connection JDBC par utilisateur?
 
si 1) est oui et 2) non, tu n'as qu'a implementer un Pool de connection JDBC.
 
si 1) est oui et 2) oui, la connection JDBC est un attribut (i.e. membre) de la session utilisateur.
 
si 1) est non, tu n'as plus de problêmes!

 
Ouais, je sais pas, au départ, g tjs envie d'hériter. Ms c vrai qu'on réfléchissant, y faut pas.
Et toi Benou, ou Darklord, vous avez pas une idée pour ma question d'avant:
une instance de Connection pour ma servlet ou une à chaque nouvelle session ?

therier a écrit a écrit :     Je pense (mais je peux me tromper...) que tu t'embrouille un peu...   tu devrais te poser les questions suivantes (i.e. faire un peu de conception):   1) ai je plusieurs utilisateurs simultanés? 2) ai je besoin d'une connection JDBC par utilisateur?   si 1) est oui et 2) non, tu n'as qu'a implementer un Pool de connection JDBC.   si 1) est oui et 2) oui, la connection JDBC est un attribut (i.e. membre) de la session utilisateur.   si 1) est non, tu n'as plus de problêmes!

 
Ouais, enfin, une servlet avec 1 seul utilisateur à la fois, ça perd quand même vachement d'intérêt !
C quoi un pool de connection !?
la question 2, c justement ce que je me demande...
comment avoir les meilleurs perfs ?

as tu besoin de gérer des commit, rollback et autre joyeuseries ?
si ou -> une par session, si non je pense qu'une seule peut suffir.
 
je dois t'avouer qu'avec le peu de jdbc que j'ai fait, j'ouvrais une connection à chaque requête BDD Mais bon, ca doit pas être très efficace

el_gringo a écrit a écrit :     Ouais, enfin, une servlet avec 1 seul utilisateur à la fois, ça perd quand même vachement d'intérêt ! C quoi un pool de connection !? la question 2, c justement ce que je me demande... comment avoir les meilleurs perfs ?

 
Il y a plusieurs params qui rentrent en ligne de compte (c'est reparti pour les p'tits numeros! ) :
 
1) le nb d'utilisateur simultané sur ta base (de connections ouvertes en même temps). Generalement, on aime bien 'brider' le nb max pour une bonne stabilité. Tu es aussi peut être limité en nb de connections suivant ta base...
 
2) le type de requetes que tu fais (sont ce toujours les même?)  
 
 
Un pool de connection, c'est un tableau ou tu declare un nombre n de connection à ta base et elle sont affectées aux utilisateurs selon un principe de tourniquet par exemple. Quand l'utilisateur a fini, la connection est disponible pour quelqu'un d'autre. Si il n'y a plus de connections dispo : soit tu agrandi ton pool, soit tu jettes l'utilisateur.
 
Je pense que c'est la meilleure des solutions (c pas dur a faire en plus).

Aprés, tu as d'autre moyen d'optimiser. Utiliser les PreparedStatment par exemple...

therier a écrit a écrit :     Il y a plusieurs params qui rentrent en ligne de compte (c'est reparti pour les p'tits numeros! ) :   1) le nb d'utilisateur simultané sur ta base (de connections ouvertes en même temps). Generalement, on aime bien 'brider' le nb max pour une bonne stabilité. Tu es aussi peut être limité en nb de connections suivant ta base...   2) le type de requetes que tu fais (sont ce toujours les même?)       Un pool de connection, c'est un tableau ou tu declare un nombre n de connection à ta base et elle sont affectées aux utilisateurs selon un principe de tourniquet par exemple. Quand l'utilisateur a fini, la connection est disponible pour quelqu'un d'autre. Si il n'y a plus de connections dispo : soit tu agrandi ton pool, soit tu jettes l'utilisateur.   Je pense que c'est la meilleure des solutions (c pas dur a faire en plus).

 
J'essayerai ça alors.
C bisard qu'il y ai pas de classe qui fasse ça dans le JDK !

 
heu, ça je l'aurai plutot utilisé en 1er ! c + simple que les pools et compagnie !

benou a écrit a écrit : as tu besoin de gérer des commit, rollback et autre joyeuseries ? si ou -> une par session, si non je pense qu'une seule peut suffir.   je dois t'avouer qu'avec le peu de jdbc que j'ai fait, j'ouvrais une connection à chaque requête BDD Mais bon, ca doit pas être très efficace

 
Non, commit et rollback, je m'en passe, au moins au début en tt cas !

 
Oui, mais ça a aucun rapport!
 
d'un coté tu optimise le traitement de la requete, de l'autre tu gere mieux tes connections.
 
Il faut faire les 2.

Je t'ai envoyé un truc la dessus en message privé.

therier a écrit a écrit :     Oui, mais ça a aucun rapport!   d'un coté tu optimise le traitement de la requete, de l'autre tu gere mieux tes connections.   Il faut faire les 2.

 
Ouais, normal. Merci. J'vais voir ton message privé qd j'aurais le temps...

Yess, g trouvé un pool de connexions. Il fait parti du projet Jakarta. Nom du sous projet: protomatter
C exactement ce que je voulais, en + ça a l'air simple d'utilisation. Génial !
Pour les interressés:
http://protomatter.sourceforge.net/
Avec les sources et tout et tout !
D'ailleur, qqn sait si on a le droit d'utilise ça à des fins commerciales !?
Donc, maintenant, j'ai le .jar qui contient les classes nécessaire au fonctionnement de ce pool.
Mais 2 questions naissent alors.
 
La suite dans ce nouveau topic :
http://forum.hardware.fr/forum2.ph [...] h=&subcat=

[jfdsdjhfuetppo]--Message édité par el_gringo le 30-05-2002 à 11:13:58--[/jfdsdjhfuetppo]

je le vois pas mentioné sur le site de jakarta ...

 
C normal, je me suis planté.
ç sur source forge, c tout !
Rien à voir avec Jakarta. Dsl pr le temps que je t'ai fait perdre à chercher !
Et toi Benou, t'as une idée la dessus: Tu crois que je peut diffuser le Jar de protomatter avec ma servlet (commerciale) ou pas !?

[jfdsdjhfuetppo]--Message édité par el_gringo le 30-05-2002 à 15:16:52--[/jfdsdjhfuetppo]

c'est bien gentil de t'excuser de m'avoir fais perdre mon temps, mais sur ce coup là t'aurais pu chercher un peu :
 

 
tu vas là http://protomatter.sourceforge.net/ et tu cliques sur "What is Protomatter?" et t'as la réponse.

 
Ha ouais. Bah, encore désolé alors !  
Mais c trop cool. J'y croyais pas. J'pensais même pas que ça existait des librairies libres pour usage commerciale. G du mal à comprendre l'intéret du type. Juste un bienfaiteur pour les entreprises !? C bon l'altruisme qd même !
J'mettre son nom quelque part dans la doc.
Et merci Benou.