Come forzare manualmente un commit in un metodo @Transactional?

Question

Sto utilizzando Spring/Spring-data-JPA e mi trovo a dover forzare manualmente un commit in un test di unità. Il mio caso d'uso è che sto facendo un test multi-thread in cui devo usare i dati che vengono mantenuti prima che i thread vengano spawnati.

Sfortunatamente, poiché il test è in esecuzione in una transazione @Transactional, anche un flush non lo rende accessibile ai thread generati.

@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()); 
    } 

Ho provato con il gestore di entità, ma un messaggio di errore quando lo faccio:

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) 

C'è un modo per commettere la transazione e continuare? Non sono stato in grado di trovare alcun metodo che mi permetta di chiamare uno commit().

Answer 1

Avevo un caso d'uso simile durante il test degli ascoltatori di eventi di ibernazione che sono chiamati solo su commit.

La soluzione era di avvolgere il codice in modo persistente in un altro metodo annotato con REQUIRES_NEW. (In un'altra classe) In questo modo viene generata una nuova transazione e un flush/commit viene emesso una volta che il metodo ritorna.

Tenete a mente che questo potrebbe influenzare tutte le altre prove! Quindi scriverli di conseguenza o è necessario assicurarsi di poter ripulire dopo il test eseguito.

Answer 2

Perché non utilizzare la molla TransactionTemplate per controllare le transazioni a livello di codice? Potresti anche ristrutturare il tuo codice in modo che ogni "blocco di transazione" abbia il proprio metodo @Transactional, ma dato che si tratta di un test, opterei per il controllo programmatico delle tue transazioni.

Si noti inoltre che l'annotazione @Transactional sul runnable non funzionerà (a meno che non si utilizzi aspectj) poiché i runnables non sono gestiti da primavera!

@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

So che a causa di questa brutta anonima utilizzo classe interna di TransactionTemplate non sembra bello, ma quando per qualche motivo vogliamo avere un metodo di prova transazionale IMHO è la l'opzione più flessibile.

In alcuni casi (dipende dal tipo di applicazione) il modo migliore di utilizzare le transazioni nei test di primavera è uno @Transactional disattivato sui metodi di prova. Perché? Perché @Transactional potrebbe portare a molti test falsi positivi. Puoi guardare questo sample article per scoprire i dettagli. In questi casi, TransactionTemplate può essere perfetto per controllare i limiti delle transazioni quando vogliamo tale controllo.