Transaction not rolled back on a JDBC manual commit / Spring transaction / MySQL InnoDB

[Stephane Eybert]

Hi,

I have an integration test and am trying to have the database go back to its original state at the end of the test run.

The MySQL table has the InnoDB engine.

The test is based on the Spring AbstractTransactionalJUnit4SpringContextTests class.

There is a transaction manager:

	<bean id="transactionManager"
		class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
		<property name="dataSource" ref="dataSource" />
	</bean>

	<tx:annotation-driven transaction-manager="transactionManager" />

The log shows the transaction being rolled back:

2012-03-09 10:32:20,990 DEBUG [DataSourceTransactionManager] Initiating transaction rollback
2012-03-09 10:32:20,990 DEBUG [DataSourceTransactionManager] Rolling back JDBC transaction on Connection [com.mysql.jdbc.JDBC4Connection@979f67]
2012-03-09 10:32:20,991 DEBUG [DataSourceTransactionManager] Releasing JDBC Connection [com.mysql.jdbc.JDBC4Connection@979f67] after transaction
2012-03-09 10:32:20,992 DEBUG [DataSourceUtils] Returning JDBC Connection to DataSource
2012-03-09 10:32:20,993 INFO [TransactionalTestExecutionListener] Rolled back transaction after test execution for test context [[TestContext@105bd58 testClass = GInnAdresseDaoTest, testInstance = no.nki.sesam.dao.GInnAdresseDaoTest@1d1e730, testMethod = testInsertAndFindWithId@GInnAdresseDaoTest, testException = [null], mergedContextConfiguration = [MergedContextConfiguration@1a116c9 testClass = GInnAdresseDaoTest, locations = '{classpath:integration.jdbc.xml, classpath:dao.xml, classpath:integration.data-source.xml}', classes = '{}', activeProfiles = '{}', contextLoader = 'org.springframework.test.context.support.DelegatingSmartContextLoader']]]

Maybe it is due to the manual commit in the JDBC dao ?

	public void insert(GInnAdresse gInnAdresse) throws SesamSqlException {
		String sql = "insert into g_inn_adresse values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, null);";
		Connection connection = null;
		try {
			connection = dataSource.getConnection();
			connection.setAutoCommit(false);
			PreparedStatement preparedStatement = connection.prepareStatement(sql);
			preparedStatement.setInt(1, gInnAdresse.getId());
			preparedStatement.setString(2, gInnAdresse.getOpprettet());
			preparedStatement.setInt(3, gInnAdresse.getAdr_id());
			preparedStatement.setString(4, gInnAdresse.getNbr_id());
			preparedStatement.setInt(5, gInnAdresse.getKun_kundenr());
			preparedStatement.setInt(6, gInnAdresse.getAns_id());
			preparedStatement.setString(7, gInnAdresse.getKde_id());
			preparedStatement.setString(8, gInnAdresse.getKua_k_adr_type());
			preparedStatement.setString(9, gInnAdresse.getLnd_kode());
			preparedStatement.setString(10, gInnAdresse.getPos_postnr());
			preparedStatement.setString(11, gInnAdresse.getAdr_adr1());
			preparedStatement.setString(12, gInnAdresse.getAdr_adr2());
			preparedStatement.setString(13, gInnAdresse.getAdr_tlf());
			preparedStatement.setString(14, gInnAdresse.getAdr_fax());
			preparedStatement.setString(15, gInnAdresse.getAdr_utl());
			preparedStatement.setString(16, gInnAdresse.getAdr_endret_dato());
			preparedStatement.executeUpdate();
			logger.debug(preparedStatement.toString());
			connection.commit();
			preparedStatement.close();
		} catch (SQLException e) {
			throwCustomException(connection, e);
		} finally {
			try {
				connection.setAutoCommit(true);
			} catch (SQLException e) {
				ExceptionUtils.printRootCauseStackTrace(e);
			}
			if (connection != null) {
				try {
					connection.close();
				} catch (SQLException e) {
	            	ExceptionUtils.printRootCauseStackTrace(e);
				}
			}
		}
	}

Any idea ?

Stephane

[James Boswell]

Stephane

In general terms, this looks a bit hacky to me.

- set auto commit to false
- commit a change
- set auto commit to true

Why are you doing this?

[Stephane Eybert]

Good question.

I was thinking I should put the auto commit state back in its original default value.

But do I need to do that ? Probably no in fact.

I removed the code chunk:

try {
connection.setAutoCommit(true);
} catch (SQLException e) {
ExceptionUtils.printRootCauseStackTrace(e);
}

but it did not help.

The roll back still is not happening.

[Rob Spoor]

Why would it perform a rollback? That only occurs if auto-commit is turned off and you a) close the connection without committing, or b) call rollback(). I see neither.

[Stephane Eybert]

I went for a

protected NamedParameterJdbcTemplate namedParameterJdbcTemplate;

public void setDataSource(DataSource dataSource) {
this.namedParameterJdbcTemplate = new NamedParameterJdbcTemplate(dataSource);
}

and the transaction behaves nicely now.

I guess I was mixing two different things, handling the connection manually inside a Spring transaction was not a good idea.