For some very bizarre reasons, we need to call some SQL after we have save or updated an object in Hibernate.

We get the connection from hibernate's session, and then issue our JDBC executeUpdate. it appears to work, but I want to make sure there aren;t any edges cases to worry about.

There may be other issues, but here are the two I worry about:

1) We use the generated ID from the saved object in the JDBC call. I assume we should call session.fluch() to ensure that any new object has an ID generated.

2) We want all this to be in one JDBC (SQL) transaction. If the JDBC call fails we want to rollback all the changes since we called session.beginTransaction(). Do tx.rollback() and tx.commit() affect other JDBC calls on the session's connection? Does a flush issue a commit for any sort?

1) session.save() returnes the generated id anyways, so there should be no need to flush()

2) just use session.connection() always and use the hibernate transaction api, this covers exactly this. flush() of course does not commit. Only commit() does flush

Thank you, that is what I was hoping.

Is save() guaranteed to return the id even if the generator is native? I'm guessing that would imply a round trip to the db on each save?

We use saveOrUpdate which has no return value. In that case, under what situations can we expect that a newly created object will have an ID assigned? I'm gussing thta a call to flush() might be prudent here (and probably just as efficient given that the saveOrUpdate call in question is the last hibernate operation before commit of rollback.

Let's have a look at the source (this is open source you know):

saveOrUpdate() just calls to save() in case of a unsaved object, but ignores the return value of the save() call. So yes, the object passed to saveOrUpdate should have an id assigned afterwards. If you want to check further, look at the source yourself :)

And yes, this might involve another database roundtrip, unless you use getGeneratedKeys.