TransactionStatus.flush() does not trigger TransactionSynchronization.flush() when using DataSourceTransactionManager, even though this transaction manager supports transaction synchronization, while the same call with JtaTransactionManager and WebSphereUowTransactionManager does.
Given that TransactionSynchronization support is implemented in AbstractPlatformTransactionmanager I would expect this behaviour to be consistent between the various TMs that derive from this.
DefaultTransactionStatus.flush() delegates to SmartTransactionObject.flush() (if the underlying transaction object implements that interface), but then some of the STO implementations call TransactionSynchronizationUtils.triggerFlush() and some don't. Maybe a more appropriate approach would be to have DefaultTransactionStatus itself call triggerFlush() directly after calling STO.flush() and removing the call from the STO sub-classes.
Another wrinkle is that the transaction manager may have been configured to not enable transaction synchronization, in which TransactionSynchronizationUtils.triggerFlush() will raise an IllegalStateException, so DefaultTransactionStatus should probably check for isSynchronizationActive first.
(As motivation for all this, I'm using Ebean ORM with Spring's transaction management, and would like it to be able to correctly participate via it's TransactionSynchronization listener when flush() is called. My workaround is currently to register another TransactionSynchronization before calling TransactionStatus.flush(), and then checking if the flush() call has been propagated, and calling triggerFlush myself otherwise, however this seems pretty hacky.)