Discussion :

[Hesiode]

Bonjour,

J'ai une appli en client lourd avec accès à une base de donnée.
Je me connecte à cette base avec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

conn = DriverManager.getConnection("jdbc:h2:chemin;AUTO_SERVER=TRUE", "login", "mdp");

Actuellement je passe en paramètre la variable "conn" à tous mes objets qui ont besoin d'accéder à la base.
Cela fonctionne très bien mais c'est pas tres pratique.

N'y aurait-il pas une autre solution ?

Merci

[tchize_]

dans les autres solutions tu as par exemple

-> stockage dans un variable statique
-> stockage comme entrée dans un JNDI

[Jidefix]

Bonjour,
personnellement quand je n'utilise pas le framework hibernate j'ai pris l'habitude de toujours passer par une seule et unique classe qui va gérer tout ce qui est connexion (et éventuellement datasource).
A travers cette classe, j'envoie des requêtes et elle me renvoie le résultat.

L'avantage est que ça sépare bien l'accès et le traitement, justement au cas où j'aurai besoin de changer un truc commun çà toutes mes requêtes, genre un traitement lié aux requêtes (log...) ou une adresse de connexion

[Hesiode]

Oui mais il faut bien que tu passes ton object "database" aux autres classes non ?
A moins que tu lances une nouvelle connection à chaque fois ?

en tout cas merci, pour le moment je vais utiliser "static" comme le preconise tchize_

[Uther]

Sauf que cette classe peut être un singleton (du coup un reviens vers l'idée du static).

[Jidefix]

Ben justement la classe a stocké la connexion en variable statique

En gros elle possède deux fonctions "usuelles":
public int update(String requete) qui va faire un executeUpdate
public ResultSet select(String requete) qui va faire un executeQuery

C'est très basique, l'intérêt est juste de centraliser tous les appels.

[Hesiode]

C'est parfait !!! parfait !!
Je devrais pouvoir rendre mon code beaucoup plus lisible !!

Merci à tout le monde !!

[tchize_]

je vais enfoncer un peu le couteau. Dans le cas de codes multiutilisateurs (plusieurs connection) on passe par une variable de type ThreadLocal, qui a une valeur différente pour chaque thread, ainsi on isole chaque utilisateur dans un thread séparé

[Jidefix]

je vais enfoncer un peu le couteau. Dans le cas de codes multiutilisateurs (plusieurs connection) on passe par une variable de type ThreadLocal, qui a une valeur différente pour chaque thread, ainsi on isole chaque utilisateur dans un thread séparé

Ca veut dire une connexion par utilisateur? Faut prévoir un bon gros pool de connexion pour ça non?
Par ailleurs dans quel contexte peux-tu dire qu'un utilisateur = un Thread? Dans une application Swing (plusieurs Thread d'éxécution) ou une web-application (euh... aucune idée de la gestion des Thread) par exemple ce n'est pas le cas non?

Je demande parce que la seule fois ou j'ai entendu parler du ThreadLocal ça m'a pourri la vie...:'( (comportements en debug et en exécution bout en bout différents)

[tchize_]

un thread n'arrête jamais un travail temporairement pour en faire un autre. Ainsi tu a la garantie que si tu fais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
try{
threadLocal.set(valeur)
// plein de machin
} finally {
 threadLocal.set(null)
}

tout ton code 'plein de machin' aura accès à valeur. Dans le cas d'une application web (un servlet par exemple) tu as la garantie que tant que ta servlet n'a pas fini son travail, tu ne change pas d'utilisateur. Bien sur une fois le travail fini, ton conteneur réutilisera le thread pour un autre utilisateur