You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using multiple datasources, integration tests using transactions in the setupSpec will fail with an UnexpectedRollbackException. A minimal sample project is available at https://gist.github.com/d2e416f2539f51945b1d.git (base64decode and unzip - if there's a better way "attach" things, let me know).
I've debugged this and found the cause for it. In GrailsTestTransactionInterceptor it builds up a list of transaction-managers, and then calls rollback on each one at the end of the test. The problem now stems from the fact that the default dataSource's transaction-manager is actually a ChainedTransactionManager, which means that in destroy() it ends up doing a rollback twice on the second datasource's transaction-manager (first indirectly via the ChainedTransactionManager, and then again via a direct call in GrailsTestTransactionInterceptor.destroy()).
I'm not sure of the correct fix, but just not adding the non-default datasources to the transactionManagers (e.g. by commenting out the lines 49 - 53) does solve the problem in this instance.
This was encountered and debugged on grails 2.5.0.
The text was updated successfully, but these errors were encountered:
When using multiple datasources, integration tests using transactions in the setupSpec will fail with an UnexpectedRollbackException. A minimal sample project is available at https://gist.github.com/d2e416f2539f51945b1d.git (base64decode and unzip - if there's a better way "attach" things, let me know).
I've debugged this and found the cause for it. In GrailsTestTransactionInterceptor it builds up a list of transaction-managers, and then calls rollback on each one at the end of the test. The problem now stems from the fact that the default dataSource's transaction-manager is actually a ChainedTransactionManager, which means that in destroy() it ends up doing a rollback twice on the second datasource's transaction-manager (first indirectly via the ChainedTransactionManager, and then again via a direct call in GrailsTestTransactionInterceptor.destroy()).
I'm not sure of the correct fix, but just not adding the non-default datasources to the transactionManagers (e.g. by commenting out the lines 49 - 53) does solve the problem in this instance.
This was encountered and debugged on grails 2.5.0.
The text was updated successfully, but these errors were encountered: