public static synchronized boolean executeBatch(List<String> sqlStatement){
  boolean batchOk=false;
  logger.trace("executeBatch() -->entry");
  final Statement S=getStatement();
  if (S == null) {
    logger.error("executeBatch() <--exit (Statement unavailable)");
    return false;
  }
  try {
    for (int i=0; i < sqlStatement.size(); i++) {
      S.addBatch(sqlStatement.get(i));
    }
    logger.trace("executeBatch(): starting Transaction...");
    startTransaction(S.getConnection());
    S.executeBatch();
    batchOk=true;
  }
 catch (  Throwable t) {
    surfaceThrowable("executeBatch() failed",t);
  }
 finally {
    try {
      endTransaction(S.getConnection(),batchOk);
    }
 catch (    Throwable t) {
      logger.error("Error encountered ending the transaction.",t);
    }
    cleanup(S);
  }
  logger.trace("executeBatch() <--exit: " + batchOk);
  return batchOk;
}

public static synchronized boolean executeBatch ( List < String > sqlStatement ) { boolean batchOk = false ; logger . trace ( "executeBatch() -->entry" ) ; final Statement S = getStatement ( ) ; if ( S == null ) { logger . error ( "executeBatch() <--exit (Statement unavailable)" ) ; return false ; } try { for ( int i = 0 ; i < sqlStatement . size ( ) ; i ++ ) { S . addBatch ( sqlStatement . get ( i ) ) ; } logger . trace ( "executeBatch(): starting Transaction..." ) ; startTransaction ( S . getConnection ( ) ) ; S . executeBatch ( ) ; batchOk = true ; } catch ( Throwable t ) { surfaceThrowable ( "executeBatch() failed" , t ) ; } finally { try { endTransaction ( S . getConnection ( ) , batchOk ) ; } catch ( Throwable t ) { logger . error ( "Error encountered ending the transaction." , t ) ; } cleanup ( S ) ; } logger . trace ( "executeBatch() <--exit: " + batchOk ) ; return batchOk ; }
this method executes a batch of input sql statements , as a " rollback - able " transaction . though these will typically be dml statements , they need not be . however , since any and all resultsets produced by query statements which might be included in the input sqlstatement list < > are implicitly discarded when the associated statement is close ( ) ' d , it is currently nonsensical to include query statements . if and when that sort of functionality is required , this method might be changed to return some sort of " result array " . note ( s ) : ade core ' s usage of derby assumes that the current database has " autocommit = = true " , by default . this effectively rules out multi - statement transactions . we take the same approach as ade core , explicitly suspending the connection ' s autocommit for the duration of the batch execution . any table - specific serialization should be done thru sql ( e . g . , " lock table xyz in exclusive mode " ) , and this kind of statement would presumably be specified by the caller as something like sqlstatement [ 0 ] .
