Adam Hardy on 01/05/08 17:48, wrote:
Adam Hardy on 30/04/08 21:22, wrote:
If I am running JPA in extended persistence context, when I call
EntityManager.merge() within a transaction and then commit the
transaction, should it or shouldn't it execute the SQL?
I assumed that it would but I have a situation where it won't unless I
call EntityManager.flush() before committing the transaction.
I'd really appreciate an answer on this one from anyone - I find the
documentation either too obtuse or too scant to get myself a firm enough
understanding of the situation I'm tackling at the moment.
Maybe it would be simpler if I just explained what I was doing:
I'm running JPA with an extended persistence context in a webapp, using the
OpenEntityManagerInView filter to open the entity manager at the start of a
request and to close it after the JSPs have finished.
I use Spring TransactionManager to wrap my persists, merges and removes.
In this current situation, I put bad data into an entity and try to display the
real exception - at the moment I only see a stacktrace in the browser relating
to a secondary exception sparked by after-effects of the first.
I would like the TransactionManager to cause a commit when it unbinds from the
EntityManager.
If I put a flush() into the code after the JPA operation, it tries to commit and
throws an exception, but it also scrubs my entity from the EntityManager and
then my JSPs can't do any lazy loading to display the data again (and give the
user a second chance to enter correct data).
So what am I doing wrong? Have I mis-configured the Spring TransactionManager
somehow? Is there a JPA setting I should be using? Should I be doing something
completely different?
