Prev: Parser to read configuration file
Next: Version problem causing issues after removal
From: Robert Klemme on 18 May 2010 17:21
On 05/18/2010 07:30 PM, carmelo wrote:
> Solved!
> The problem was on reading... it was necessary to synchronize entities
> with a loop of entityManager.refresh(entity);

So you sticked with your two EntityManagers? In that case you have at
best a workaround - but not a proper solution.

Good luck!

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
From: Arved Sandstrom on 18 May 2010 18:30
Robert Klemme wrote:
> On 05/18/2010 07:30 PM, carmelo wrote:
>> Solved!
>> The problem was on reading... it was necessary to synchronize entities
>> with a loop of entityManager.refresh(entity);
>
> So you sticked with your two EntityManagers? In that case you have at
> best a workaround - but not a proper solution.
>
> Good luck!
>
> robert
>
And in my experience - admittedly anecdotal - refresh() doesn't figure
all that much. It's usually not the proper choice if your understanding
of JPA isn't solid.

In a couple of largish J2EE applications that I have worked with
extensively over the past while, the *only* use of refresh is for
operations support people who have to do manual database work to
fix/reverse certain actions in the field; refresh() is used on the
entities that have just been modified directly, because we can't restart
the application. That is, there is "backout" functionality in the app
for refreshing entities that are known to have been changed.

I have to agree with Robert, this doesn't feel like a solution.

AHS
First  |  Prev  | 
Pages: 1 2
Prev: Parser to read configuration file
Next: Version problem causing issues after removal