No effective change - update on Transaction

src/main/java/io/ebean/Transaction.java

@@ -288,36 +288,66 @@ public interface Transaction extends AutoCloseable {
   boolean isSkipCache();
 
   /**
-   * Turn on or off statement batching. Statement batching can be transparent
-   * for drivers and databases that support getGeneratedKeys. Otherwise you may
-   * wish to specifically control when batching is used via this method.
-   * <p>
-   * Refer to <code>java.sql.PreparedStatement.addBatch();</code>
-   * <p>
-   * Note that you may also wish to use the setPersistCascade method to stop
-   * save and delete cascade behaviour. You may do this to have full control
-   * over the order of execution rather than the normal cascading fashion.
-   * </p>
-   * <p>
-   * Note that the <em>execution order</em> in batch mode may be different from
-   * non batch mode execution order. Also note that <em>insert behaviour</em>
-   * may be different depending on the JDBC driver and its support for
-   * getGeneratedKeys. That is, for JDBC drivers that do not support
-   * getGeneratedKeys you may not get back the generated IDs (used for inserting
-   * associated detail beans etc).
-   * </p>
+   * Turn on or off use of JDBC statement batching.
    * <p>
    * Calls to save(), delete(), insert() and execute() all support batch
-   * processing. This includes normal beans, MapBean, CallableSql and UpdateSql.
+   * processing. This includes normal beans, CallableSql and UpdateSql.
    * </p>
+   *
+   * <pre>{@code
+   *
+   * try (Transaction transaction = server.beginTransaction()) {
+   *
+   *   // turn on JDBC batch
+   *   transaction.setBatchMode(true);
+   *
+   *   // tune the batch size
+   *   transaction.setBatchSize(50);
+   *
+   *   ...
+   *
+   *   transaction.commit();
+   * }
+   *
+   * }</pre>
+   *
+   * <h3>getGeneratedKeys</h3>
    * <p>
-   * The flushing of the batched statements is automatic but you can call
-   * batchFlush when you like. Note that flushing occurs when a query is
-   * executed or when you mix UpdateSql and CallableSql with save and delete of
+   * Often with large batch inserts we want to turn off getGeneratedKeys. We do
+   * this via {@link #setBatchGetGeneratedKeys(boolean)}.
+   * Also note that some JDBC drivers do not support getGeneratedKeys in JDBC batch mode.
+   * </p>
+   * <pre>{@code
+   *
+   * try (Transaction transaction = server.beginTransaction()) {
+   *
+   *   transaction.setBatchMode(true);
+   *   transaction.setBatchSize(100);
+   *   // insert but don't bother getting back the generated keys
+   *   transaction.setBatchGetGeneratedKeys(false);
+   *
+   *
+   *   // perform lots of inserts ...
+   *   ...
+   *
+   *   transaction.commit();
+   * }
+   *
+   * }</pre>
+   *
+   * <h3>Flush</h3>
+   * <p>
+   * The batch is automatically flushed when it hits the batch size and also when we
+   * execute queries or when we mix UpdateSql and CallableSql with save and delete of
    * beans.
    * </p>
    * <p>
-   * Example: batch processing executing every 3 rows
+   * We use {@link #flush()} to explicitly flush the batch and we can use
+   * {@link #setBatchFlushOnQuery(boolean)} and {@link #setBatchFlushOnMixed(boolean)}
+   * to control the automatic flushing behaviour.
+   * </p>
+   * <p>
+   * Example: batch processing of CallableSql executing every 10 rows
    * </p>
    *
    * <pre>{@code
@@ -332,13 +362,13 @@ public interface Transaction extends AutoCloseable {
    * CallableSql cs = new CallableSql(sql);
    * cs.registerOut(2, Types.INTEGER);
    *
-   * // (optional) inform eBean this stored procedure
+   * // (optional) inform Ebean this stored procedure
    * // inserts into a table called sp_test
    * cs.addModification("sp_test", true, false, false);
    *
    * try (Transaction txn = ebeanServer.beginTransaction()) {
    *   txn.setBatchMode(true);
-   *   txn.setBatchSize(3);
+   *   txn.setBatchSize(10);
    *
    *   for (int i = 0; i < da.length;) {
    *     cs.setParameter(1, da[i]);