anchor.diff:  		}
   
   		public int[] batchUpdate(final List<Actor> actors) {
  -			int[] updateCounts = jdbcTemplate.batchUpdate("update t_actor set first_name = ?, " +
  -					"last_name = ? where id = ?",
  -				new BatchPreparedStatementSetter() {
  -					public void setValues(PreparedStatement ps, int i) throws SQLException {
  +			return this.jdbcTemplate.batchUpdate(
  +					"update t_actor set first_name = ?, last_name = ? where id = ?",
  +					new BatchPreparedStatementSetter() {
  +						public void setValues(PreparedStatement ps, int i) throws SQLException {
   							ps.setString(1, actors.get(i).getFirstName());
   							ps.setString(2, actors.get(i).getLastName());
   							ps.setLong(3, actors.get(i).getId().longValue());
   						}
  -
   						public int getBatchSize() {
   							return actors.size();
   						}
   					});
  -			return updateCounts;
   		}
   
   		// ... additional methods
  
positive.code: ----
  	public interface PlatformTransactionManager {
  
  		TransactionStatus getTransaction(
  				TransactionDefinition definition) throws TransactionException;
  
  		void commit(TransactionStatus status) throws TransactionException;
  
  
negative.code: All of the above batch update methods return an int array containing the number of
  affected rows for each batch entry. This count is reported by the JDBC driver. If the
  count is not available, the JDBC driver returns a -2 value.
  
  [NOTE]
  ====
  In such a scenario with automatic setting of values on an underlying `PreparedStatement`,
  the corresponding JDBC type for each value needs to be derived from the given Java type.
  While this usually works well, there is a potential for issues, e.g. with Map-contained
  `null` values: Spring will by default call `ParameterMetaData.getParameterType` in such a
  case which may be expensive with your JDBC driver. Please make sure to use a recent driver
  version, and consider setting the "spring.jdbc.getParameterType.ignore" property to "true"
  (as a JVM system property or in a `spring.properties` file in the root of your classpath)
  if you encounter a performance issue, e.g. as reported on Oracle 12c (SPR-16139).
  
  Alternatively, simply consider specifying the corresponding JDBC types explicitly:
  either via a 'BatchPreparedStatementSetter' as shown above, or via an explicit type
  array given to a 'List<Object[]>' based call, or via 'registerSqlType' calls on a
  custom 'MapSqlParameterSource' instance, or via a 'BeanPropertySqlParameterSource'
  which derives the SQL type from the Java-declared property type even for a null value.
  ====
  
  
  [[jdbc-batch-multi]]
  