[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5648?page=c... ] Wallace Wadge commented on HHH-5648: ------------------------------------ Sorry, I might not have been clear. Let me try again. Let's say you have a mysql table with just 1 field - the id field - set to autoincrement so the model object only contains something like: @Id @GeneratedValue(strategy = GenerationType.AUTO) @Column( name = "id", nullable = false ) public Integer getId() { return this.id; } Now in the hibernate code, this value gets assigned as a result of the insert statement being generated. Therefore somewhere you'd have: x = insert into .... obj.setId(x); The key thing here is that this ID has been assigned to the object before the transaction has been committed. Now with a connection pool like BoneCP, you can tell the pool to record any activity on a connection and, in case of a connection failure, attempt to connect again and replay all the activity on a new connection. In plain JDBC, this is not a problem -- the database would have aborted the broken transaction and a new transaction goes thru. With hibernate however, replaying this transaction will work at a connection and database level but hibernate never gets another chance to assign the new id to the object. Continuing on the example above, now we have y = insert into ... and really we should be doing obj.setId(y) at some point. So I'm asking: is it possible to assign the ids of objects after the transaction has been confirmed as committed instead? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira