2009-10-21 11 views
0

J'ai un problème étrange avec dbUnit. J'utilise dbUnit 2.4.4, java 1.6, Spring (en tant que pool de connexion db), Oracle 9 pour mon projet avec environ 50 tests unitaires. Pour certains d'entre eux (quand je lance ensemble de tests) je reçois cette exception:Problème avec dbUnit: java.sql.SQLException: instruction fermée

Closed Statement 
[junit] junit.framework.AssertionFailedError: Closed Statement 
[junit]  at com.myproj.DataAccess.Internal.BaseDAOTest.importToDb(Unknown Source) 
[junit]  at com.myproj.DataAccess.Internal.MyDAOTest.testGetBuyClientOrders(Unknown Source) 
[junit]  at org.eclipse.ant.internal.ui.antsupport.EclipseDefaultExecutor.executeTargets(EclipseDefaultExecutor.java:32) 
[junit]  at org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.run(InternalAntRunner.java:423) 
[junit]  at org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.main(InternalAntRunner.java:137) 

charges de méthode importToDb données de test à partir du fichier XML à base de données via la méthode DatabaseOperation.REFRESH.execute de DbUnit et il est utilisé dans TOUS tests. Si j'exécute ces tests séparément, il n'y a aucun problème pour eux. Avez-vous des idées? Merci!

+0

Peut-on voir le code pour importToDb? Ta. –

+0

Ici, il est http://pastebin.com/mf19de0a – dbf

Répondre

1

Je suppose que certains de vos tests ferment la connexion à la base de données lors du nettoyage. Le test suivant essaie à nouveau d'utiliser cette connexion pour l'importation et échoue.

+0

Je ne ferme pas la connexion explicitement dans l'un des tests. Tous utilisent jdbcTemplate depuis la librairie Spring DAO, donc je n'ai pas besoin d'utiliser les connexions manuellement. Les connexions sont fermées dans la fonction d'importation, mais cette fonction est la même pour tous les tests. – dbf

+0

Quelle source de données utilisez-vous? Est-ce le 'SingleConnectionDataSource'? – tangens

+0

Description de la source de ma configuration Spring: < nom de propriété = "maxOpenPreparedStatements" value = "20" /> dbf

1

Quand cela est arrivé à moi, nous avions explicitement configuré notre cache de connexion pour canarder les connexions de longue durée en utilisant deux propriétés:

AbandonedConnectionTimeout 
InactivityTimeout 

See Oracle's docs here regarding timeout properties

Il est apparu que le temps de requête + traitement était sauter la cuspide des deux propriétés combinées (AbandonedConnectionTimeout + InactivityTimeout < heure de la requête + temps de traitement resultset).

Pour résoudre ce problème, vous pouvez augmenter vos limites de délai d'attente ou vous pouvez supprimer le délai d'attente en les mettant à 0 (la valeur par défaut)