WLS - Comment gérer la transaction

Question

J'utilise le serveur Weblogic où l'objet de connexion traite une transaction où la même instance de connexion essaie d'utiliser une transaction différente, la transaction existante ne peut pas terminer et elle renvoie une erreur de transaction, où la transaction existante est effectuer une opération de validation/restauration et une nouvelle transaction utilise également l'opération commit/rollback à partir de plusieurs procédures utilisant le même objet de connexion. Donc, est-il possible d'utiliser le même objet de connexion doit gérer la session de transaction si elle complète et pour une nouvelle nouvelle session de la transaction devrait commencer à éviter cette erreur

static { 
    Context ctx = null; 
    Hashtable ht = new Hashtable(); 
    ht.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory"); 
    ht.put(Context.PROVIDER_URL, "t3://localhost:7001"); 


    LOGGER.debug("con outside " + conn); 
    ResultSet rs = null; 
    try { 
     ctx = new InitialContext(ht); 
      javax.sql.DataSource ds 
       = (javax.sql.DataSource) ctx.lookup("jndi/mynonXADatasource"); 


     // UserTransaction tx = (UserTransaction) ctx.lookup("javax.transaction.UserTransaction"); 
     tx.begin(); 
     conn = ds.getConnection(); 
     conn.setAutoCommit(false); 

    } catch (SQLException e) { 
     LOGGER.error(e.getMessage()); 
    } catch (Exception e) { 
     LOGGER.error(e.getMessage()); 
    } 
} 

public static Connection getdatasourceconnection() { 

    try { 
     if (null == conn || conn.isClosed()) { 
      LOGGER.debug("Getting new Connection"); 
      conn = getNewConnection(); 
      return conn; 
     } 
     conn = obtainConnection(); 

    } catch (SQLException e) { 
    } 
    return conn; 
} 

private static Connection getNewConnection() { 
    Context ctx = null; 
    Hashtable ht = new Hashtable(); 

    ht.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory"); 
    ht.put(Context.PROVIDER_URL, "t3://localhost:7001"); 
    LOGGER.debug("con outside " + conn); 

    Connection oraConn;  oraConn = null; 
    try { 
     ctx = new InitialContext(ht); 
     javax.sql.DataSource ds 
       = (javax.sql.DataSource) ctx.lookup("jndi/mynonXADatasource"); 

     //UserTransaction userTransaction=(UserTransaction)ctx.lookup ("jndi/mynonXADatasource"); 
     conn = ds.getConnection(); 
     conn.setAutoCommit(false); 

     LOGGER.debug("con inside " + conn); 
     LOGGER.debug("context " + ctx); 

    } catch (SQLException e) { 
     LOGGER.error(e.getMessage()); 
    } catch (Exception e) { 
     LOGGER.error(e.getMessage()); 
    } 
    return conn; 
} 

public static void closeConnection(Connection conn) { 

    try { 
     if (null != conn) { 
      conn.close(); 
      conn = null; 
     } 
    } catch (SQLException ex) { 
     LOGGER.error(ex.getMessage()); 
    } 
} 

J'ai 15 appels de procédure magasin et en utilisant certains DML/DDL aussi et si j'essaie d'utiliser le même objet de connexion je reçois la transaction est en phase préparée/engagée comme ça, où de la procédure de magasin il y a des opérations de validation qui se passent et s'il faut du temps pour traiter un processus (JMS) essayant d'utiliser la même connexion cette erreur de transaction est en train de se produire. Existe-t-il un moyen d'utiliser le même objet de connexion sans échec de transaction au lieu d'obtenir une nouvelle connexion à chaque fois?

Answer 1

«J'ai 15 appels de procédure magasin et en utilisant certains DML/DDLs aussi ... où il y a opération de validation se passent de la procédure de magasin »

Cela semble être le point crucial de votre problème. Une unité de travail devrait être une transaction unique. Cependant, il semble que votre architecture construit une unité de travail à partir de plusieurs transactions (dans le domaine de la base de données, une transaction est l'activité entre les validations). Au minimum, vous avez besoin d'habiller votre couche de base de données avec une API dans laquelle une unité de travail est une procédure stockée unique. Cette procédure stockée peut appeler tous les procs stockés et exécuter tout le DML nécessaire, mais vous avez un appel de base de données qui s'exécute dans une session. Une fois cela fait, vous pouvez commencer à supprimer les validations des procédures de niveau inférieur et placer la gestion des transactions là où elle appartient: en haut de la pile des appels.