question about extended context and transactions

[Adam Hardy <ad...@cyberspaceroad.org>]

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.


Regards
Adam

Re: question about extended context and transactions

[Ognjen Blagojevic <og...@etf.bg.ac.yu>]

Adam Hardy wrote:
> 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?

Maybe you should try to validate the data before you try to merge it in 
the database. Most JSP framworks support validation, and it is also 
integrated in JSF.

In other words, JSP/JSF should handle validation, not DB.

Regards,
Ognjen

Re: question about extended context and transactions

[Adam Hardy <ad...@cyberspaceroad.org>]

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?

Re: question about extended context and transactions

[Adam Hardy <ad...@cyberspaceroad.org>]

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.