Wie erzwinge manuell ein Commit in einer @ Transactional-Methode?

Question

Ich benutze Spring/Spring-Daten-JPA und finde mich gezwungen, ein Commit in einem Komponententest manuell erzwingen. Mein Anwendungsfall ist, dass ich einen Multithread-Test mache, bei dem ich Daten verwenden muss, die persistent sind, bevor die Threads erzeugt werden.

Leider, da der Test in einer @Transactional-Transaktion ausgeführt wird, macht es auch eine flush nicht zugänglich für die erzeugten Threads.

@Transactional 
    public void testAddAttachment() throws Exception{ 
     final Contract c1 = contractDOD.getNewTransientContract(15); 
     contractRepository.save(c1); 

     // Need to commit the saveContract here, but don't know how!     
     em.getTransaction().commit(); 

     List<Thread> threads = new ArrayList<>(); 
     for(int i = 0; i < 5; i++){ 
      final int threadNumber = i; 
      Thread t = new Thread(new Runnable() { 
       @Override 
       @Transactional 
       public void run() { 
        try { 
         // do stuff here with c1 

         // sleep to ensure that the thread is not finished before another thread catches up 
         Thread.sleep(1000); 
        } catch (InterruptedException e) { 
         // TODO Auto-generated catch block 
         e.printStackTrace(); 
        } 
       } 
      }); 
      threads.add(t); 
      t.start(); 
     } 

     // have to wait for all threads to complete 
     for(Thread t : threads) 
      t.join(); 

     // Need to validate test results. Need to be within a transaction here 
     Contract c2 = contractRepository.findOne(c1.getId()); 
    } 

Ich habe versucht, den Entity Manager zu verwenden, aber eine Fehlermeldung zu erhalten, wenn ich tun:

org.springframework.dao.InvalidDataAccessApiUsageException: Not allowed to create transaction on shared EntityManager - use Spring transactions or EJB CMT instead; nested exception is java.lang.IllegalStateException: Not allowed to create transaction on shared EntityManager - use Spring transactions or EJB CMT instead 
    at org.springframework.orm.jpa.EntityManagerFactoryUtils.convertJpaAccessExceptionIfPossible(EntityManagerFactoryUtils.java:293) 
    at org.springframework.orm.jpa.aspectj.JpaExceptionTranslatorAspect.ajc$afterThrowing$org_springframework_orm_jpa_aspectj_JpaExceptionTranslatorAspect$1$18a1ac9(JpaExceptionTranslatorAspect.aj:33) 

Gibt es eine Möglichkeit, die Transaktion und weiterhin zu begehen? Ich konnte keine Methode finden, die es mir erlaubt, eine commit() anzurufen.

Answer 1

Ich hatte einen ähnlichen Anwendungsfall beim Testen von Hibernate Event Listeners, die nur beim Commit aufgerufen werden.

Die Lösung bestand darin, den Code dauerhaft in eine andere mit REQUIRES_NEW annotierte Methode einzubinden. (In einer anderen Klasse) Auf diese Weise wird eine neue Transaktion erzeugt und ein Flush/Commit wird ausgegeben, sobald die Methode zurückkehrt.

Beachten Sie, dass dies die anderen alle Tests beeinflussen könnten! Schreiben Sie sie entsprechend, oder Sie müssen sicherstellen, dass Sie nach dem Test räumen können.

Answer 2

Warum verwenden Sie nicht Spring TransactionTemplate, um Transaktionen programmgesteuert zu steuern? Sie könnten Ihren Code auch so umstrukturieren, dass jeder "Transaktionsblock" seine eigene @Transactional-Methode hat, aber da es sich um einen Test handelt, würde ich mich für die programmgesteuerte Kontrolle Ihrer Transaktionen entscheiden.

Beachten Sie auch, dass die Annotation @Transactional auf Ihrem Runnable nicht funktionieren wird (es sei denn, Sie verwenden aspectj), da die Runnables nicht im Frühjahr verwaltet werden!

@RunWith(SpringJUnit4ClassRunner.class) 
//other spring-test annotations; as your database context is dirty due to the committed transaction you might want to consider using @DirtiesContext 
public class TransactionTemplateTest { 

@Autowired 
PlatformTransactionManager platformTransactionManager; 

TransactionTemplate transactionTemplate; 

@Before 
public void setUp() throws Exception { 
    transactionTemplate = new TransactionTemplate(platformTransactionManager); 
} 

@Test //note that there is no @Transactional configured for the method 
public void test() throws InterruptedException { 

    final Contract c1 = transactionTemplate.execute(new TransactionCallback<Contract>() { 
     @Override 
     public Contract doInTransaction(TransactionStatus status) { 
      Contract c = contractDOD.getNewTransientContract(15); 
      contractRepository.save(c); 
      return c; 
     } 
    }); 

    ExecutorService executorService = Executors.newFixedThreadPool(5); 

    for (int i = 0; i < 5; ++i) { 
     executorService.execute(new Runnable() { 
      @Override //note that there is no @Transactional configured for the method 
      public void run() { 
       transactionTemplate.execute(new TransactionCallback<Object>() { 
        @Override 
        public Object doInTransaction(TransactionStatus status) { 
         // do whatever you want to do with c1 
         return null; 
        } 
       }); 
      } 
     }); 
    } 

    executorService.shutdown(); 
    executorService.awaitTermination(10, TimeUnit.SECONDS); 

    transactionTemplate.execute(new TransactionCallback<Object>() { 
     @Override 
     public Object doInTransaction(TransactionStatus status) { 
      // validate test results in transaction 
      return null; 
     } 
    }); 
} 

}

Answer 3

Ich weiß, dass aufgrund dieser hässlichen anonymen inneren Klasse Verwendung von TransactionTemplate nicht schön aussieht, aber wenn wir aus irgendeinem Grunde meiner Meinung nach einem Prüfverfahren Transaktions haben wollen, ist es die am flexibelsten Option.

In einigen Fällen (abhängig vom Anwendungstyp) ist die beste Möglichkeit, Transaktionen in Spring-Tests zu verwenden, ein ausgeschalteter @Transactional über die Testmethoden. Warum? Denn @Transactional kann zu vielen falsch-positiven Tests führen. Sie können dieses sample article betrachten, um Details herauszufinden. In solchen Fällen kann TransactionTemplate perfekt für die Steuerung von Transaktionsgrenzen sein, wenn wir diese Kontrolle wünschen.