Objet de connexion pour un site Web utilisant le regroupement de connexions (local ou instance)

Question

Pour une application Web avec l'interrogation de connexion activée, vaut-il mieux travailler avec un objet de connexion de portée locale ou un objet de connexion de portée d'instance. Je sais qu'il n'y a probablement pas une grande amélioration de performance entre les deux (à cause de la mise en commun) mais diriez-vous que l'un suit un meilleur modèle que l'autre. Merci;)

public class MyServlet extends HttpServlet { 
    DataSource ds; 

    public void init() throws ServletException { 
     ds = (DataSource) getServletContext().getAttribute("DBCPool"); 
    } 

    protected void doGet(HttpServletRequest arg0, HttpServletResponse arg1) throws ServletException, IOException { 
     SomeWork("SELECT * FROM A"); 
     SomeWork("SELECT * FROM B"); 
    } 

    void SomeWork(String sql) { 
     Connection conn = null; 
     try { 
      conn = ds.getConnection(); 
      // execute some sql 
      ..... 
     } finally { 
      if(conn != null) { 
       conn.close(); // return to pool 
      } 
     } 
    } 
} 

Ou

public class MyServlet extends HttpServlet { 
    DataSource ds; 
    Connection conn;* 

    public void init() throws ServletException { 
     ds = (DataSource) getServletContext().getAttribute("DBCPool"); 
    } 

    protected void doGet(HttpServletRequest arg0, HttpServletResponse arg1) throws ServletException, IOException { 
     try { 
      conn = ds.getConnection(); 
      SomeWork("SELECT * FROM A"); 
      SomeWork("SELECT * FROM B"); 
     } finally { 
      if(conn != null) { 
       conn.close(); // return to pool 
      } 
     } 
    } 

    void SomeWork(String sql) { 
     // execute some sql 
     ..... 
    } 
} 

Answer 1

Vous devez prendre cette approche:

1. Prenez une connexion de la piscine
2. Diriger une transaction complète, le déplacement de la base de données valide l'état au suivant
3. Commit
4. Retour la connexion à la piscine
5. Retour la réponse HTTP

Votre première approche n'est pas une bonne idée parce que si l'une des unités de travail échoue, vous pouvez quitter la base de données dans un état inconsistant.

Peut-être que vous terminerez la première unité de travail, puis serez incapable de prendre la deuxième connexion de la piscine (un autre thread est arrivé en premier). Peut-être que sous une lourde charge, cela arrivera à plusieurs demandes et rien ne sera fait correctement.