Hi,

I have a transaction which simply updates an element in table A. However, a number of other related elements in another table B needs to be updated whenever the element in table A is updated.

I achieve this now by doing the following:



1. If the first block fails - everything is fine. No damage done.
2. If the second block fails - then suddenly the element in table A is updated but the related elements remain unchanged.

The main issue is that if i put both the update() and executeKeywordChanged() calls in the same transaction block, then executeKeywordChanged() will be flushed immediately when i invoke the method (no matter what) as it is a native SQL query. The save() will not be flushed before commit() is invoked.

The dream scenario here would be as follows, where update() and executeKeywordChanged() would be flushed sequentially on commit().



However, this seems not to be the case. Any others with experience on this?

[/code]

You can manually execute a Session.flush() before execute the native query. Eg.

Ok,

But what i would like to achieve is that executeKeywordChanged() only is invoked if update() succeeds, and update() should be rolled back if executeKeywordChanged() fails.

Should i maybe look into database triggers for this problem?

Yes, that is exactly what happens in the example I posted. I assume that you have proper try/catch handling around the entire piece of code. eg.

My code looks as follows:



Just to make sure that i understand this completely: what you are saying is that if i change the transaction block to contain the following - then everything will be ok?



I just though that by invoking flush(), the changes would be written to the database. And, as a consequence of this, if the executeKeywordChanged() failes, then the changes made to currentNode would already be written to the database?

Is the changes made by update() + flush() actually rolled back/reverted from the database with an SQL statement if the executeKeywordChanged() fails?

Alright,

I tested your solution and it works fine! I just thought that as long a session was flushed, then things would be written to the database and things couldn't be rolled back...but it seems that my Hibernate knowledge has a few flaws :-)

Thank you very much for your speedy and great help!

Yes they are written to the database and that is good since you need the updated values in native query...



Not true. When you rollback the transaction everything that has been written is undone.



Yes, it is the call to currentSession.getTransaction().rollback() that triggers this.

OK!

Thanks a lot for your explanation!