== attempt 1: a stock Spring Boot JPA application ==
$ java -jar target/transactions-1.0.0.jar

  org.springframework.transaction.NestedTransactionNotSupportedException
  Transaction manager does not allow nested transactions by default - specify 'nestedTransactionAllowed' property with value 'true'

== attempt 2: nestedTransactionAllowed = true, as the message instructs ==
$ java -jar target/transactions-1.0.0.jar --demo.nested-allowed=true

  org.springframework.transaction.NestedTransactionNotSupportedException
  JpaDialect does not support savepoints - check your JPA provider's capabilities

A different message, from a second check. The savepoint manager is obtained from the
object the JpaDialect returns when it begins the transaction, and Hibernate's does not
implement one -- so no amount of configuration gets NESTED working here.

== attempt 3: the same propagation on a JDBC transaction manager ==
$ curl -s localhost:8081/tx/nested-jdbc

  {
      "rowsVisibleInsideNestedScope": 2,
      "nestedScopeThrew": "nested scope fails",
      "rowsAfterNestedRollback": 1,
      "rowsAfterOuterCommit": 1,
      "surviving": [
          "outer-row"
      ],
      "transactionManager": "DataSourceTransactionManager (not JpaTransactionManager)"
  }

This is what NESTED is for: the nested scope rolled back to its savepoint, the outer
transaction carried on and committed, and one of the two rows survived.

A savepoint is a JDBC concept. DataSourceTransactionManager holds the JDBC connection
and can issue one; JpaTransactionManager holds an EntityManager and cannot. The
reference documentation does say NESTED works with JDBC resource transactions -- what
it does not say is that the JPA path fails, twice, with two different messages.