java.sql.Connection non visible depuis un thread

Question

J'ai créé un thread avec les paramètres java.sql.Connection et String. Mais à partir de l'intérieur du thread, j'ai observé que la valeur String était disponible mais que l'objet Connection ne l'était pas. Des indices?

(détails Modification en question):

Eh bien, il semble l'objet de connexion est disponible, mais fermé à l'intérieur du fil. Voici le code:

package com.catgen.helper; 

import java.sql.Connection; 

public class ImageCheckHelper extends Thread{ 

    public Connection conn = null; 
    public String str = null; 

    public ImageCheckHelper(Connection conn, String str){ 
     this.conn = conn; 
     this.str = str; 
     try{ 
      System.out.println("From inside the constructor"); 
      System.out.println((this.conn!=null)?"Connection is not null":"Connection is null"); 
      System.out.println((this.str!=null)?"String is not null":"String is null"); 
      System.out.println((this.conn.isClosed())?"Connection is closed.":"Connection is not closed"); 
      System.out.println("\n\n"); 
     }catch(Exception e){ 
      e.printStackTrace(); 
     } 
    } 

    public void run(){ 
     try{ 
      System.out.println("From inside the thread"); 
      System.out.println((conn!=null)?"Connection is not null":"Connection is null"); 
      System.out.println((str!=null)?"String is not null":"String is null"); 
      System.out.println((conn.isClosed())?"Connection is closed.":"Connection is not closed"); 
     }catch(Exception e){ 
      e.printStackTrace(); 
     } 
    } 

    public void initiateImageCheck(){ 
     this.start(); 
     return; 
    } 
} 

Et voici la sortie:

From inside the constructor 
Connection is not null 
String is not null 
Connection is not closed 



From inside the thread 
Connection is not null 
String is not null 
Connection is closed. 

Answer 1

Je ne vois pas ce que votre problème est - regardant la sortie, vous pouvez voir que les deux Connection et String sont non -NULL dans le constructeur et lorsque vous venez d'exécuter le thread. La seule différence est que la connexion a été fermée à un certain point entre le thread en cours de construction et le thread en cours d'exécution. Selon la manière dont vous avez fourni la connexion et la façon dont les autres threads l'utilisaient, ce n'est pas particulièrement inhabituel. Dans tous les cas, vous devriez regarder d'autres threads en appelant close() sur le même objet Connection si vous voulez le suivre. En règle générale, il est généralement plus facile pour chaque thread de gérer sa propre connexion, car sinon vous vous retrouvez avec une sémantique très délicate sur la validation et la fermeture (comme vous l'avez vu ici). Partage d'une connexion entre plusieurs threads peut travail, et en de rares occasions est nécessaire, mais en général, il devrait être l'exception plutôt que la règle.

Éditer: En outre, beaucoup d'implémentations Connection ne sont même pas threadsafe, de sorte que vous ne pouvez pas vraiment les utiliser entre plusieurs threads d'une manière fiable. Si un thread exécute une instruction et que vous essayez ensuite d'utiliser la connexion sur un autre thread, les mauvaises choses se produiront. Encore plus de justification pour donner à chaque thread sa propre connexion et le laisser se débrouiller avec ce qu'il veut faire, sans avoir à s'engager dans une sorte de synchronisation mutex (un goulot d'étranglement qui supprime aussi une partie de l'attraction du multithreading!).

Answer 2

Un autre thread ferme-t-il la connexion entre l'heure à laquelle il est donné au constructeur et l'heure à laquelle il est utilisé dans la méthode run()? Ma conjecture est que la connexion est fermée après l'appel de startsImageCheck() mais avant que la méthode run() ne soit aussi loin que la vérification isClosed().

Si non, avez-vous accès au code source du pilote JDBC? Je me demande s'il se protège contre l'utilisation multi-thread.

Les connexions ne sont pas forcément thread-safe, vous devez donc obtenir la connexion depuis le thread qui va l'utiliser.

Vous disposez également d'un accès non synchronisé à conn à partir de deux threads différents. Les variables de membre public ne sont pas non plus une bonne idée - en particulier dans les classes qui doivent être thread-safe.