Lorsqu'il s'agit de transactions dans le test de printemps, il est essentiellement annulé après la méthode de test. Cependant, dans le cas d'une méthode de test qui utilise Spring Batch, une erreur d'exécution se produit. La cause en sera expliquée un peu plus tard, mais si vous utilisez une transaction démarrée en dehors de Spring Batch en interne, si vous validez ou annulez sans connaître Spring Batch, la gestion de l'état du lot peut devenir étrange. Il semble que.
Cependant, le comportement de ce Spring Batch gêne lors de l'exécution avec spring-test. Pour résoudre ce problème rapidement, procédez comme suit.
MapJobRepositoryFactoryBean b = new MapJobRepositoryFactoryBean();
b.setValidateTransactionState(false);
En définissant setValidateTransactionState sur false, le contrôle d'existence de transaction mentionné ci-dessus ne sera pas effectué. Le javadoc de la méthode a la description suivante.
* Flag to determine whether to check for an existing transaction when a
* JobExecution is created. Defaults to true because it is usually a
* mistake, and leads to problems with restartability and also to deadlocks
* in multi-threaded steps.
L'utilisation de transactions en dehors de Spring Batch est fondamentalement une erreur, qui peut entraver le redémarrage et également entraîner des blocages dans les étapes multithreads. une. Je ne pense pas que ce soit un problème dans le cas des tests unitaires.
Cela étant dit, je pense qu'il est normal de l'effacer avec DBUnit ou DbSetup à chaque fois. Bien sûr, c'est désavantageux en termes de vitesse.