title: Why does the Spring Data JPA query fail when using the specified transaction manager?
body: <p>I have a service which uses to 2 datasources - one that handles reads and one that handles modifying operations (insert, delete, update). For each datasource, I have configured a distinct transaction manager.</p>
  <p>The default transaction manager named simply <code>transactionManager</code> handles reads, while the other one named <code>writeTransactionManager</code> handles writes.</p>
  <p>Everything works fine for reads, but I have a <code>custom delete query</code> which simply isn't picked up by the right transaction manager.</p>
  <p>This is my repository:</p>
  <pre><code>public interface DeviceWriteRepository extends JpaRepository&lt;Device, String&gt; {
      @Transactional
      @Modifying
      @Query(&quot;DELETE FROM Device d WHERE d.userId = ?1 AND d.tenantId = ?2 AND d.appId = ?3&quot;)
      void unregisterDevices(String userId, String tenantId, String appId);
  }
  </code></pre>
  <p>Having enabled the debug and trace JPA/Hibernate logs, when I call the <code>unregisterDevices</code> devices I get the following logs:</p>
  <pre><code>Creating new transaction with name [com.my.app.repository.SoftDeleteCrudRepositoryImpl.unregisterDevice]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
  Opened new EntityManager [SessionImpl(1270255427&lt;open&gt;)] for JPA transaction
  Exposing JPA transaction as JDBC [org.springframework.orm.jpa.vendor.HibernateJpaDialect$HibernateConnectionHandle@464a9dcc]
  delete from device where user_id=? and tenant_id=? and app_id=?
  delete from device where user_id=? and tenant_id=? and app_id=?
  binding parameter [1] as [VARCHAR] - [user1]
  binding parameter [2] as [VARCHAR] - [someTenant]
  binding parameter [3] as [VARCHAR] - [someApp]
  Initiating transaction commit
  Committing JPA transaction on EntityManager [SessionImpl(1270255427&lt;open&gt;)]
  Closing JPA EntityManager [SessionImpl(1270255427&lt;open&gt;)] after transaction
  </code></pre>
  <p>Everything is fine and if I check the database, the delete query worked, but it wasn't executed by the <code>writeTransactionManager</code>.</p>
  <p>To force the use of my desired transaction manager, I update the <code>@Transactional</code> annotation to include the name of manager as such <code>@Transactional(&quot;writeTransactionManager&quot;)</code>, I get the following exception:</p>
  <pre><code>org.springframework.dao.InvalidDataAccessApiUsageException: Executing an update/delete query; nested exception is javax.persistence.TransactionRequiredException: Executing an update/delete query
  </code></pre>
  <p>Moreover, if I check the logs again, I can see that unlike in my first attempt, the <code>writeTransactionManager</code> is actually picked as per the following logs with emphasis on the <strong>first line</strong>:</p>
  <pre><code>Creating new transaction with name [com.my.app.repository.SoftDeleteCrudRepositoryImpl.unregisterDevice]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT; 'writeTransactionManager'
  Opened new EntityManager [SessionImpl(1868680430&lt;open&gt;)] for JPA transaction
  Exposing JPA transaction as JDBC [org.springframework.orm.jpa.vendor.HibernateJpaDialect$HibernateConnectionHandle@1c459897]
  Opening JPA EntityManager
  Initiating transaction rollback
  Rolling back JPA transaction on EntityManager [SessionImpl(1868680430&lt;open&gt;)]
  Closing JPA EntityManager [SessionImpl(1868680430&lt;open&gt;)] after transaction
  </code></pre>
  <p>How can this not be inside a transaction but the initial one is? Why does specifying the name of the transaction manager break the behaviour?</p>
  <p>One more thing I'd like to mention is I have also tried using the DSL and define a different repository method like this:</p>
  <pre><code>@Transactional(&quot;writeTransactionManager&quot;)
  void deleteByUserIdAndTenantIdAndAppIdAndPlatform(String userId, String tenantId, String appId, PlatformType platform);
  
  </code></pre>
  <p>When I use this method, the <code>writeTransactionManager</code> is picked up, but it first does <code>SELECT</code> query to bring in the managed entities - and surprise - the delete never happens.</p>