anchor.diff:  from the `jee` namespace. For more information see
   <<integration.adoc#xsd-schemas-jee, The JEE Schema>>.
   
  -You can also use easily Hibernate local transactions, as shown in the following
  -examples. In this case, you need to define a Hibernate `LocalSessionFactoryBean`,
  -which your application code can use to obtain Hibernate `Session` instances.
  -
  -The `DataSource` bean definition is similar to the local JDBC example shown
  -previously and, thus, is not shown in the following example.
  +You can also easily use Hibernate local transactions, as shown in the following examples.
  +In this case, you need to define a Hibernate `LocalSessionFactoryBean`, which your
  +application code can use to obtain Hibernate `Session` instances.
  +
  +The `DataSource` bean definition is similar to the local JDBC example shown previously
  +and, thus, is not shown in the following example.
   
   NOTE: If the `DataSource` (used by any non-JTA transaction manager) is looked up through
   JNDI and managed by a Java EE container, it should be non-transactional, because the
   Spring Framework (rather than the Java EE container) manages the transactions.
   
   The `txManager` bean in this case is of the `HibernateTransactionManager` type. In the
  -same way as the `DataSourceTransactionManager` needs a reference to the `DataSource`,
  -the `HibernateTransactionManager` needs a reference to the `SessionFactory`.
  -The following example declares `sessionFactory` and `txManager` beans:
  +same way as the `DataSourceTransactionManager` needs a reference to the `DataSource`, the
  +`HibernateTransactionManager` needs a reference to the `SessionFactory`. The following
  +example declares `sessionFactory` and `txManager` beans:
   
   [source,xml,indent=0,subs="verbatim,quotes"]
   ----
  
positive.code: necessary. It is not tied to a lookup strategy, such as JNDI.
  `PlatformTransactionManager` implementations are defined like any other object (or bean)
  in the Spring Framework IoC container. This benefit alone makes Spring Framework
  transactions a worthwhile abstraction, even when you work with JTA. You can test transactional code
  much more easily than if it used JTA directly.
  
  Again, in keeping with Spring's philosophy, the `TransactionException` that can be thrown
  by any of the `PlatformTransactionManager` interface's methods is unchecked (that
  
negative.code: 	}
  ---- 
  
  The reactive transaction manager is primarily a service provider interface (SPI),
  although you can use it <<transaction-programmatic-rtm, programmatically>> from your
  application code. Because `ReactiveTransactionManager` is an interface, it can be easily
  mocked or stubbed as necessary.
  
  The `TransactionDefinition` interface specifies:
  
  