DataSourceTransactionManager triggers flush callbacks on registered transaction synchronizations

Issue: SPR-14847
(cherry picked from commit 2874066)

Author: jhoeller

spring-jdbc/src/main/java/org/springframework/jdbc/datasource/DataSourceTransactionManager.java

@@ -1,5 +1,5 @@
 /*
- * Copyright 2002-2015 the original author or authors.
+ * Copyright 2002-2016 the original author or authors.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -28,6 +28,7 @@
 import org.springframework.transaction.support.DefaultTransactionStatus;
 import org.springframework.transaction.support.ResourceTransactionManager;
 import org.springframework.transaction.support.TransactionSynchronizationManager;
+import org.springframework.transaction.support.TransactionSynchronizationUtils;
 
 /**
  * {@link org.springframework.transaction.PlatformTransactionManager}
@@ -47,14 +48,14 @@
  *
  * <p>Application code is required to retrieve the JDBC Connection via
  * {@link DataSourceUtils#getConnection(DataSource)} instead of a standard
- * J2EE-style {@link DataSource#getConnection()} call. Spring classes such as
+ * Java EE-style {@link DataSource#getConnection()} call. Spring classes such as
  * {@link org.springframework.jdbc.core.JdbcTemplate} use this strategy implicitly.
  * If not used in combination with this transaction manager, the
  * {@link DataSourceUtils} lookup strategy behaves exactly like the native
  * DataSource lookup; it can thus be used in a portable fashion.
  *
  * <p>Alternatively, you can allow application code to work with the standard
- * J2EE-style lookup pattern {@link DataSource#getConnection()}, for example for
+ * Java EE-style lookup pattern {@link DataSource#getConnection()}, for example for
  * legacy code that is not aware of Spring at all. In that case, define a
  * {@link TransactionAwareDataSourceProxy} for your target DataSource, and pass
  * that proxy DataSource to your DAOs, which will automatically participate in
@@ -87,6 +88,12 @@
  * DBCP connection pool). Switching between this local strategy and a JTA
  * environment is just a matter of configuration!
  *
+ * <p>As of 4.3.4, this transaction manager triggers flush callbacks on registered
+ * transaction synchronizations (if synchronization is generally active), assuming
+ * resources operating on the underlying JDBC {@code Connection}. This allows for
+ * setup analogous to {@code JtaTransactionManager}, in particular with respect to
+ * lazily registered ORM resources (e.g. a Hibernate {@code Session}).
+ *
  * @author Juergen Hoeller
  * @since 02.05.2003
  * @see #setNestedTransactionAllowed
@@ -368,6 +375,13 @@ public void setRollbackOnly() {
 		public boolean isRollbackOnly() {
 			return getConnectionHolder().isRollbackOnly();
 		}
+
+		@Override
+		public void flush() {
+			if (TransactionSynchronizationManager.isSynchronizationActive()) {
+				TransactionSynchronizationUtils.triggerFlush();
+			}
+		}
 	}
 
 }

spring-tx/src/main/java/org/springframework/transaction/TransactionStatus.java

@@ -1,5 +1,5 @@
 /*
- * Copyright 2002-2013 the original author or authors.
+ * Copyright 2002-2016 the original author or authors.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -80,6 +80,10 @@ public interface TransactionStatus extends SavepointManager, Flushable {
 	/**
 	 * Flush the underlying session to the datastore, if applicable:
 	 * for example, all affected Hibernate/JPA sessions.
+	 * <p>This is effectively just a hint and may be a no-op if the underlying
+	 * transaction manager does not have a flush concept. A flush signal may
+	 * get applied to the primary resource or to transaction synchronizations,
+	 * depending on the underlying resource.
 	 */
 	@Override
 	void flush();