For purposes of migrating data with existing entity IDs, we use the following code to turn on and off IDENTITY INSERT (we are using SQL Server) on a certain table:
Code:
public class SqlServerIdentityInsertToggle implements Work
{
protected boolean identityInsertOn = false;
protected String tableName;
...
@Override
public void execute(Connection connection) throws SQLException
{
String schema = AccountInformationContextHolder.getAccountSchema();
StringBuilder sql = new StringBuilder("SET IDENTITY_INSERT ");
if(schema != null && !schema.isEmpty())
sql.append(schema).append(".");
sql.append(this.tableName).append(" ").append(this.identityInsertOn ? "ON" : "OFF");
try(PreparedStatement statement = connection.prepareStatement(sql.toString()))
{
statement.executeUpdate();
}
}
}
Code:
SqlServerIdentityInsertToggle idToggle = new SqlServerIdentityInsertToggle(tableName);
idToggle.setIdentityInsertOn(true);
session.doWork(idToggle);
session.save(entity);
idToggle.setIdentityInsertOn(false);
session.doWork(idToggle);
This code and the use of it has not changed. Where as with Hibernate 3.5.1 it was just working, now with Hibernate 4.1.3 we are getting the following error:
"Cannot insert explicit value for identity column in table ‘table’ when IDENTITY_INSERT is set to OFF."
This obviously doesn't seem right. We performed a SQL Server Profiler trace on the code as it was executing and got this:
Code:
SET IMPLICIT_TRANSACTIONS ON
go
declare @p1 int
set @p1=55
exec sp_prepare @p1 output,N'',N'SET IDENTITY_INSERT ------censored------ ON',1
select @p1
go
exec sp_execute 55
go
declare @p1 int
set @p1=56
exec sp_prepare ------censored------
select @p1
go
exec sp_execute ------censored------
go
IF @@TRANCOUNT > 0 ROLLBACK TRAN
go
IF @@TRANCOUNT > 0 COMMIT TRAN
SET IMPLICIT_TRANSACTIONS OFF
go
The setting of IMPLICIT_TRANSACTIONS to ON bothers me. This indicates that Transaction#setAutoCommit(boolean) is true. But this should not be the case. Reading Hibernate code clearly shows me that setAutoCommit(false) is called when a transaction is begun. So why would IMPLICIT_TRANSACTIONS be ON?
We are using Spring's @Transactional and Hibernate Transaction Manager to manage our transactions. We know this is working because before and after the Hibernate upgrade, removing @Transactional from a method resulted in an error about no existing transaction to retrieve.
This was our environment when we were using Hibernate 3.5.1:
SQL Server 2008 R1 SP1
jTDS JDBC Driver 1.2.5
Java 6
Tomcat 6
Spring 3.0.5
And this is our environment now that we are using Hibernate 4:
SQL Server 2008 R1 SP1
jTDS JDBC Driver 1.2.5
Java 7
Tomcat 7
Spring 3.1.2
Clearly, other things have changed. Unfortunately, this bug went several months without being noticed (poor testing on our part). We can rule out the server or the driver; they are exactly the same as before.
I doubt Java 7 is the culprit; seems we would get some kind of error if this were somehow causing problems.
Our data source definitions have not changed between Tomcat, and the Tomcat documentation states that the DBCP policy has not changed between 6 and 7; autoCommit still defaults to the driver default (e.g., setAutoCommit is simply not called unless specified in the data source definition). So I don't think that's the culprit either.
That leaves Spring. This seems the change most likely to have impacted this behavior. However, I spent a couple hours searching, reading and comparing the Spring code, and A) there are only 5 or 6 uses of setAutoCommit, none having to do with Hibernate transaction support, and B) none of them have changed between 3.0.5 and 3.1.2.
I'm scratching me head over here. Surely we're doing something wrong, but I just can't lay my finger on it.
Thoughts? Suggestions?
Login
FAQ
Search