openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <>
Subject Re: question about extended context and transactions
Date Thu, 01 May 2008 17:06:07 GMT
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 

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?

View raw message