Comment faire pour contourner la connexion JDBC sans utiliser Spring/JPA/Hibernate

Question

Nous avons une application Java J2EE qui utilisait des appels de service Web individuels pour chaque insertion/mise à jour de ligne de base de données. Cela s'est avéré être trop lent. Ils m'ont amené à "rapidement" le réparer. Je prévois de convertir tous les appels de service Web en JDBC simple. Pour ce faire, je dois obtenir une connexion JDBC à partir du pool, puis l'utiliser dans plusieurs méthodes différentes. J'ai besoin d'utiliser la même connexion JDBC dans plusieurs DAO pour tout enchaîner dans une seule transaction de base de données. Je peux passer explicitement la connexion JDBC à chaque DAO qui en a besoin, mais cela nécessiterait de changer BEAUCOUP de signatures de méthodes, plus beaucoup de tests unitaires (ce qui va à l'encontre de la partie "rapidement").

J'essaye de trouver un bon moyen de mettre la connexion JDBC quelque part et ensuite de la saisir dans les méthodes qui en ont besoin sans avoir à la passer partout. Nous ne pouvons pas utiliser Spring, JPA ou Hibernate sur ce projet car l'équipe de support ne prend pas en charge ces technologies. Je peux mettre la connexion JDBC dans un EJB, mais je ne suis pas sûr de sa fiabilité. Je pourrais créer un singleton personnalisé pour gérer les connexions de base de données pour chaque utilisateur (session?), Mais je devrais faire attention à la sécurité des threads. Si quelqu'un a déjà essayé de faire quelque chose comme ça, j'apprécierais quelques conseils.

Answer 1

Vous pouvez utiliser un ThreadLocal. Avoir le point d'entrée et le mettre en place que les OTI

class ConnectionUtil { 
    public static final ThreadLocal<Connection> connection = new ThreadLocal<Connection>(); 
} 

public Return method(Args arg) { 
    ConnectionUtil.connection.set(newConnection()); 
    try { 
     ... 
    } finally { 
     ConnectionUtil.connection.remove(); 
    } 
} 

assez laid, mais qui semble être ce que votre patron veut.

Answer 2

Nous l'avons déjà fait (il y a 5 ans sur IBM WebSphere). Nous avons écrit un pool et stocké les connexions jdbc dans une table de hachage avec le sessionID. Le seul piège était de fermer la connexion sur sessionend et de la renvoyer au pool (nous l'avons fait avec un sessionlistener). Si une session utilisateur se connecte uniquement à une connexion jdbc, la sécurité du thread est héritée. Donc, l'approche singleton fonctionne vraiment. Notre gain de performance était horrible.

Answer 3

Utilisez Apache Commons DBCP. C'est le projet de pool de connexions d'Apache, et ce qui est utilisé en interne dans de nombreux moteurs.

Answer 4

De plus, ce que j'ai fait pour les DAO dans ce cas n'est pas de passer la connexion dans la signature de la méthode mais dans le constructeur. Ensuite, je tiens l'objet qui crée à l'origine la connexion responsable de le fermer.